Description Gordon Yorke 2011-01-10 15:03:13 EST

There is a conflict between batch writing and how EclipseLink acquires internal locks on the cache.  If the batch "buffer" has pending writes the "buffer" will not be flushed until after the UOW has attempted to acquire its locks.  The UOW is unaware that there are pending updates before it attempts to acquire the needed locks.

If another thread has locked those same rows that the first thread has not yet locked because of the unflushed buffer and then attempts to acquire cache locks it will have to wait on the first thread.  The first thread with the buffered batch writes will not be able to complete it's txn and release the cache locks because it will not be able to complete the writes to the database.

There are two simple workarounds :
 1) Using a SessionCustomizer in EclipseLink change the cache transaction isolation:

        public void customize(Session session) throws Exception{
            ... // other customizations
            session.getLogin().setCacheTransactionIsolation(DatasourceLogin.SYNCRONIZED_OBJECT_LEVEL_READ_WRITE);
        }

  This will cause EclipseLink to acquire locks only after the transaction has been committed.  This may result in a slight increase in Optimistic Lock occurrences but will continue to maintain data integrity in the cache with out impacting performance.

 2) remove batch writing. However, this is likely to have a major impact on performance.