openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Curtis (JIRA)" <>
Subject [jira] [Assigned] (OPENJPA-2472) Concurrency issue in ClassMetaData.getPkAndNonPersistentManagedFmdIndexes()
Date Wed, 05 Feb 2014 23:02:08 GMT


Rick Curtis reassigned OPENJPA-2472:

    Assignee: Rick Curtis

> Concurrency issue in ClassMetaData.getPkAndNonPersistentManagedFmdIndexes()
> ---------------------------------------------------------------------------
>                 Key: OPENJPA-2472
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 2.2.2, 2.3.0
>            Reporter: Benjamin Bentmann
>            Assignee: Rick Curtis
>         Attachments: OPENJPA-2472.txt
> In a scenario where brand new entity instances of the same class get inserted concurrently,
we noticed sporadic failures like this:
> Caused by: <openjpa-2.3.0-r422266:1540826 fatal store error> org.apache.openjpa.persistence.EntityNotFoundException:
The transaction has been rolled back.  See the nested exceptions for details on the errors
that occurred.
> 	at org.apache.openjpa.kernel.BrokerImpl.newFlushException(
> 	at org.apache.openjpa.kernel.BrokerImpl.flush(
> 	at org.apache.openjpa.kernel.BrokerImpl.flushSafe(
> 	at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(
> 	at org.apache.openjpa.kernel.LocalManagedRuntime.commit(
> 	at org.apache.openjpa.kernel.BrokerImpl.commit(
> 	at org.apache.openjpa.kernel.DelegatingBroker.commit(
> 	at org.apache.openjpa.persistence.EntityManagerImpl.commit(
> 	... 2 more
> Caused by: <openjpa-2.3.0-r422266:1540826 nonfatal store error> org.apache.openjpa.persistence.EntityNotFoundException:
The instance of type "class ..." with oid "ec2cfaa9e2f04b628d7e1991e65751dc" no longer exists
in the data store.  This may mean that you deleted the instance in a separate transaction,
but this context still has a cached version.
> 	at org.apache.openjpa.kernel.StateManagerImpl.loadFields(
> 	at org.apache.openjpa.kernel.StateManagerImpl.loadField(
> 	at org.apache.openjpa.kernel.StateManagerImpl.fetchStringField(
> 	at org.apache.openjpa.kernel.StateManagerImpl.fetchString(
> 	at org.apache.openjpa.jdbc.meta.strats.StringFieldStrategy.insert(
> 	at org.apache.openjpa.jdbc.meta.FieldMapping.insert(
> 	at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.insert(
> 	at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.populateRowManager(
> 	at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(
> 	at org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(
> 	at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(
> 	at org.apache.openjpa.kernel.DelegatingStoreManager.flush(
> 	... 9 more
> The primary ID of each entity is set manually by the app prior to insertion.
> Debugging led me to ClassMetaData.getPkAndNonPersistentManagedFmdIndexes() which is called
from StateManagerImpl.initialize() to set up the _loaded bit set. When the above exception
occurs, all bits in that set are zero. This ultimately caused the erroneous loadField() call
that fails the insertion.
> The following line in getPkAndNonPersistentManagedFmdIndexes() disturbs the thread-safety:
> _pkAndNonPersistentManagedFmdIndexes = new int[idsSize];
> Once this has executed, another thread which executes the if (_pkAndNonPersistentManagedFmdIndexes
== null) in line 2778 can read the array before the first thread has finished the loop that
initializes its values.
> The line following "// Default to FALSE, until proven true." in hasPKFieldsFromAbstractClass()
looks equally troublesome, setting an instance variable to a temp value. Somebody whose more
familar with the codebase might want to check for more occurrences of this pattern.

This message was sent by Atlassian JIRA

View raw message