Datastore Connections

DataNucleus utilises datastore connections as follows

• EMF : single connection at any one time for datastore-based value generation. Obtained just for the operation, then released
• EMF : single connection at any one time for schema-generation. Obtained just for the operation, then released
• EM : single connection at any one time. When in a transaction the connection is held from the point of retrieval until the transaction commits or rolls back. The exact point at which the connection is obtained is defined more fully below. When used for non-transactional operations the connection is obtained just for the specific operation.

For pessimistic (or datastore) transactions when begin() is called on the transaction, a connection will be obtained to the datastore. This datastore connection will be held for the duration of the transaction until such time as either commit() or rollback() are called.

For optimistic transactions things are a little more complicated. The call to begin() has no effect with respect to datastore connections. All updates to the datastore are delayed until flush() or commit() and so no connection is obtained until that time. When flush() is called, or the transaction committed a datastore connection is finally obtained and it is held open until commit/rollback completes. when a datastore operation is required. The connection is typically released after performing that operation. So datastore connections, in general, are held for much smaller periods of time. This is complicated slightly by use of the PMF property java.jdo.option.IgnoreCache . When this is set to false , the connection, once obtained, is not released until the call to commit()/rollback().

If you have multiple threads using the same PersistenceManager then you can get "ConnectionInUse" problems where another operation on another thread comes in and tries to perform something while that first operation is still in use. This happens because the JPA spec requires an implementation to use a single datastore connection at any one time. When this situation crops up the user ought to use multiple EntityManagers.

Another important aspect is use of queries for Optimistic transactions, or for non-transactional contexts. In these situations it isn't possible to keep the datastore connection open indefinitely and so when the Query is executed the ResultSet is then read into core making the queried objects available thereafter.