Thread Safety

[craigmcdonnell]

Hi all, I've recently read http://www.javalobby.org/articles/thread-safe/index.jsp and http://static.springframework.org/sp...rence/orm.html whilst investigating thread safety issues to be expected in a Tomcat / Spring MVC / Hibernate application I am writing for university.

From reading the article and the referenced Spring docs, it seems HibernateTemplate is thread safe. Great But, does this mean Thread safety is now handled for my situation (I'm guessing not!) or are readers / writers problems still to be expected? If so, please could someone provide hints as to where I should expect them to occur?

Best regards,

Craig

ps. Sorry if this seems like a request for a 101 on concurrency and thread safety I'm still pretty new to the intricacies of Servlets / Spring / Hibernate :s

[craigmcdonnell]

Hmmm... more specifically:

If I had an AtmServlet similar to that shown in example 5.5 of http://www.unix.org.ua/orelly/java-e...t/ch05_05.htm; but retrieved the Account act variable from a DAO using HibernateTemplate....

1) Would the act variable contain the same object reference across multiple threads?
2) If (1)==true, I'm guessing I'd still need to synchronize access in the following lines?:

    synchronized(act) {
      if(req.getParameter("WITHDRAW") != null) && (amt < act.balance)
        act.balance = act.balance - amt;
      if(req.getParameter("DEPOSIT") != null) && (amt > 0)
        act.balance = act.balance + amt;
    } // end synchronized block

3) If (1)==false, how would conflicting concurrent changes be resolved when writing threads commit transactions?

Thanks.
Craig

[dejanp]

If "act" is a local variable it's threadsafe. If it's an instance variable, it's not.

[craigmcdonnell]

Thanks dejanp. To confirm, whilst HibernateTemplate is thread safe, any domain object it returns is not (inherently) even when pesimistic transaction locking is applied. (?)
For any two threads requesting access to a domain object from HibernateTemplate, they will both obtain a reference to the same in memory object. (?) Therefore, reading/writing to this object carried out by the Service layer must be synchronized to be thread safe (?)

Or, can pesimistic locking help avoid interference issues?

Thanks.

[dejanp]

No, you will get one instance of an entity per thread/session/transaction. Anything else would make any kind of Hibernate use an exercise in self-torture.

[Alarmnummer]

Thanks dejanp. To confirm, whilst HibernateTemplate is thread safe
, any domain object it returns is not (inherently) even when pesimistic transaction locking is applied. (?)

Concurrency control can be done in 3 different ways:
-isolation: object should only be used in a single thread thereby preventing concurrent access (there is no shared state)
-immutability: if there is no shared mutable state, there is no need to protect data
-synchronization: if there is shared mutable state, this state needs to be protected.

Spring applications normally rely on the first two techniques to deal with concurrency control. Synchronization is much more complex and you don't want to do it on a daily basis.

Domain objects usually are isolated (confined) to a single thread, so since the object is not shared, no synchronization is required. The database entities (the records) are shared mutable state, so they require some form of synchronization. This can be done in different ways: transactions, select for update. But some database (like Oracle, Postgresql) provide some very nice tricks as well (MVCC).

For any two threads requesting access to a domain object from HibernateTemplate, they will both obtain a reference to the same in memory object. (?)

Not correct. Only in a single session (transaction) you will receive the same object (or a crappy proxy to that object). But getting the same entity from different sessions, will return different objects.

Therefore, reading/writing to this object carried out by the Service layer must be synchronized to be thread safe (?)

Not correct. Depending on the type of lock you are using, you could bring the system to a grinding halt (lock contention) because all service requests would need to be serialized.

Service layer normally is immutable, so no synchronization is needed. In most cases using the database transaction is good enough to protect you against concurrency issues.

Or, can pesimistic locking help avoid interference issues?

I suggest reading 'Patterns of Enterprise Application Architecture' from martin fowler. It has a chapter about concurrency control in enterprise systems. It also talks about optimistic/pessimistic and online/offline locking.

Ps: next to the standard concurrency problems (caused by too much or too less synchronization) a system could also be subject to Visibility and Reordering problems. I suggest 'Java Concurrency in Practice' from Brian Goetz for more info about this (interesting) subject.

[craigmcdonnell]

Thank you both so much! Alarmnummer, I shall be borrowing Martin Fowler's book from the university library this evening
...'Java Concurrency in Practice' has had to go onto my Amazon wishlist

To summarise what I now believe to be the case: domain objects are isolated (not shared across threads) and can be protected from concurrency issues via DB transactions.
For utility classes (e.g. those of Castor) use the following to avoid concurrency issues use:
-isolation (preferred)
-immutability (preferred)
-synchronization

Thanks again to both of you for your time and responses.