openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Grassel <>
Subject JPA 2.0 EntityManager.refresh() Behavior
Date Wed, 05 May 2010 15:05:28 GMT
I've encountered some behaviors in OpenJPA which I did not expected, and wanted to hear out
from the community whether or not these are bugs in the product.

The first one is with how EntityManager.refresh() works when the data cache is enabled.  Page
105 in the JPA 2.0 Spec states "The retrieveMode property is ignored for the refresh method,
which always causes data to be retrieved from the database, not the cache."  However, it looks
like refresh() is going to the cache for state information instead of directly accessing the
database for a fresh set of data.  I've confirmed this by setting up a JDBCListener, and no
observable SQL is captured by the refresh() operation.


The next issue I ran into is when I issue a refresh() requesting a lock, and specifying a
timeout hint with it.  It looks like the timeout works, but instead of getting a LockTimeoutException
or a PessimisticLockException, I get the following OptimisticLockException:

org.apache.openjpa.persistence.OptimisticLockException:Unable to obtain an object lock on
FailedObject: entities.EntityA-1 [java.lang.String]
	at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(
	at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(
	at org.apache.openjpa.jdbc.sql.DB2Dictionary.newStoreException(
	at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(
	at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(
	at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(
	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.syncVersion(
	at org.apache.openjpa.kernel.DelegatingStoreManager.syncVersion(
	at org.apache.openjpa.kernel.ROPStoreManager.syncVersion(
	at org.apache.openjpa.kernel.StateManagerImpl.syncVersion(
	at org.apache.openjpa.kernel.StateManagerImpl.beforeRefresh(
	at org.apache.openjpa.kernel.BrokerImpl.refreshInternal(
	at org.apache.openjpa.kernel.BrokerImpl.refresh(
	at org.apache.openjpa.kernel.DelegatingBroker.refresh(
	at org.apache.openjpa.persistence.EntityManagerImpl.refresh(
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: Processing was cancelled due
to an interrupt.. SQLCODE=-952, SQLSTATE=57014, DRIVER=3.51.76 {prepstmnt 1166493063 SELECT
[params=(int) 1]} [code=-952, state=57014]
	at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(
	at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(
	at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(
	at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeQuery(
	at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeQuery(
	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeQuery(
	at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeQuery(
	at org.apache.openjpa.jdbc.sql.SelectImpl.executeQuery(
	at org.apache.openjpa.jdbc.sql.SelectImpl.execute(
	at org.apache.openjpa.jdbc.sql.SelectImpl.execute(
	at org.apache.openjpa.jdbc.meta.strats.ColumnVersionStrategy.checkVersion(
	at org.apache.openjpa.jdbc.meta.Version.checkVersion(
	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.syncVersion(
	... 38 more

While on the locking topic, I found that the hint javax.persistence.lock.scope = PessimisticLockScope.EXTENDED
with refresh() seems to be ignored -- I seen no SQL sent to the database which attempted to
lock the related rows in the join table, even after establishing the lock with the refresh()
and walking through the *:many relationship list to see if the SQL generated to access the
join table to fetch entities addressed by the relationship would become locked -- they did

View raw message