Where Does ObjectDB Block/Lock?

These are questions asked in the context of the proposed architecture described in the forum thread titled, "Sample JDO Architecture for Follow Up Questions".

Questions about blocking/locking.  With my PersistenceManager multiThreaded=true architecture, I desire to know where ObjectDB is actually blocking/locking so I might adapt to achieve better concurrency.

1) Where are locks when accessing PersistenceManager by multiple threads?

2) Does it lock at PersistenceManager.currentTransaction()?

3) Does it lock at transaction.begin() if optimistic=false? 

4) Does it lock at transaction.commit() if optimistic=true?

5) ObjectDB 1.0 Manual (Support > Knowledge Base > ObjectDB 1.0 Manual > 5. JDO Connections >5.3  javax.jdo.Transaction > Automatic Lock Management > Last sentence) states "On short running transactions, however, or when the probability for lock conflicts is high, datastore transactions are preferred."  But, newer version 2.6.8_05 ObjectDB defaults optimistic=true, perhaps implying optimistic=true now has less overhead either way.  Maybe a shared single PersistenceManager (multiThreaded=true) makes all my requests sequential and therefore ObjectDB 1.0 Manual's statement suggests datastore transactions (optimistic=false) would be faster.  With my described multithreaded and queued architecture, with high throughput, especially on read, is desired, should I use optimistic=true to get more concurrency?

All relevant PersistenceManager / Transaction methods are synchronized so multiple threads should be able to access and use a shared PersistenceManager instance safely. ObjectDB ignores the setting of multiThreaded=true. However, if you want to serve requests against the same database concurrently (not in a queue) you will need multiple PersistenceManager instances.

In ObjectDB 1.x pessimistic locks were more efficient, but with ObjectDB 2.x optimistic locks are faster.

With the willingness to use the queue of a single PersistenceManager with optimistic locking, the call to transaction.commit() is where entity object locking actually happens.  Does this mean that all other activity/calls to PersistenceManager from many threads are all happening concurrently up to the point where transaction.commit() is called?

> Does this mean that all other activity/calls to PersistenceManager from many threads are all happening concurrently up to the point where transaction.commit() is called?

No. Almost all the PersistenceManager / Transaction methods are synchronized. Therefore, operations against the database (with a shared PersistenceManager) are not concurrent. Still, transactions are concurrent, since transactions may include many operations. On commit (or flush) optimistic lock checks verify that different transactions do not conflict. This check is also against other users that use separate PersistenceManager instances (if any).