Immutable Classes / Threadsafety Questions

eeverman · **Posted:** Wed May 30, 2007 10:24 am

I have a set of related tables with a minimal amount of data that changes slowly (weekly) and I would like to use Hibernate to load it into a class tree. These objects would then participate in highly concurrent, read-only environment (a web service).

I'm reading _Java Concurrency in Practice_ by Brian Goetz. Based on my reading, a completely immutable class would look like this:

Code:

public class Book {
  private final String name;
  private final Long id;

  public Book(String n, Long i) {
    name = n;  id = i;
  }

  public String getName() { return name; }
  public Long getId() { return id; }
}

Unfortunately, it is not possible to add a no-arg constructor to this because the instance vars may not have been initialized. Also, using final variables means that they cannot be initialized with a set method, so Hibernate would need to initialize the final field values via reflection - is this construction even possible with Hibernate??

In general, are there any guaranties that field values written by Hibernate (either by set methods or field reflection) are visible to other threads? Using the volitile keyword is supposed to ensure values are always written back to the heap - should volitile be used for fields of domain objects managed by Hibernate?

Thanks,

--ee

eeverman · **Posted:** Wed May 30, 2007 4:49 pm

Any comments on this??

satsranchuser · **Posted:** Wed May 30, 2007 5:17 pm

I don't think a variable that is declared final can be manipulated with a setter method. So to answer your question No hibernate will be do anything about this.

eeverman · **Posted:** Wed May 30, 2007 5:48 pm

satsranchuser wrote:

I don't think a variable that is declared final can be manipulated with a setter method. So to answer your question No hibernate will be do anything about this.

Well, in JDK 1.5, it is possible to 'flip' the final flag, though I imagine that would negate its usefulness.

I guess my question is, given that final is not really feasible, should volatile be used for all instance variables of shared objects to ensure field visibility of Hibernate managed objects?

Without a volatile or final marker on a field, there is no JVM guarantee that changes made to an instance variable will be visible to other threads, unless the code writing and reading the variable are synchronized using the same object.

Anyone?

Tama · **Joined:** Tue May 08, 2007 8:43 pm **Posts:** 5

Hibernate does NOT require your getters or setters to be public - private is enough. In this case, writing some private setters for your fields and adding a private constructor would do the trick; your objects would be writable by Hibernate, but still immutable from the rest of the world's point of view.

So your class would look like this:

Code:

public class Book {
  private final String name;
  private final Long id;
  
  private Book() {}
  
  public Book(String n, Long i) {
    name = n;  id = i;
  }

  private void setName(final String name) { this.name = name; }
  private void setId(final Long id) { this.id = id; }
  
  public String getName() { return name; }
  public Long getId() { return id; }
}

You will get more details here: http://www.javalobby.org/java/forums/t49288.html

dshk · **Joined:** Tue Feb 08, 2005 7:01 am **Posts:** 21

Tama wrote:

private setters for your fields and adding a private constructor would do the trick; your objects would be writable by Hibernate, but still immutable from the rest of the world's point of view.

The objects will be immutable, but still they won't be thread safe. I think the only way (other then (1) synchronizing on the whole collection or (2) creating a similar second class with final fields and copying the state of the Hibernate compatible object to the thread safe object) is to customize Hibernate by creating a custom tuplizer(?), which can use a constructor instead of setter methods or direct field access to initialize the object. However I haven't tried this yet...