Hi All,
Hi James,
I checked your suggestion. The locking of the database isn't the real
problem. In this particular case all TopLink actions are flushed to the
database - however the final commit to the database connection isn't sent.
After this use case, regardless how many EntityTransactions are opened
and closed the EntityManager does no more revover - it remains in the
inconsistent state (everything is synchronized with the database, but
not committed).
We are able to commit the DB-connection using the reference from the
DatabaseAccessor - this workaround works well.
Do you have an idea what could cause TopLink not to decrease the value
of the attribute depth in the ConcurrencyManager and cause so this
inconsistency?
At the end of all subsequent transactions the depth value is still 2,
but should be 1. Only, then the database commit is initiated by TopLink....
However TopLink essentials is really great product - other persistence
providers (Hibernate, openJPA) cannot handle this complexity at all :-).
thank you in advance,
regards,
adam
James Sutherland schrieb:
> Turn logging on to finest and see when a beginTransaction() call occurs on
> the TopLink session.
> Also check if any exceptions are occurring.
> What are you doing exactly to recreate the issue, try to narrow down the
> cause.
> Are you executing any native SQL, or queries using pessimistic locking?
> They may be triggering a begin of a transaction that the EntityManager is
> not aware of.
>
>
>
> Adam Bien wrote:
>
>> Hi All,
>>
>> in a really complex (deep inheritance-hiearchies of persistent entites,
>> bidirectional references etc.) JPA Entity Model we have some problems
>> with committing the transaction into the database.
>>
>> Use Case: Adding an additional relation to a bidirectional @OneToMany
>> relation causes the inconsistency in a specific context. However it is a
>> specific case - other Use Cases work without any problems. Remove and
>> all other operations work as well.
>>
>> It turns out, that in this particular case the
>> java.sql.Connection.commit() isn't invoked. The problem is somehow
>> related with the
>> oracle.toplink.essentials.internal.helper.ConcurrencyManager and it's
>> depth field. At the end of the transaction the depth is greater than
>> one, so the final connection.commit isn't executed (TopLink thinks,
>> there are still some ongoing transactions). The problem here: all
>> following operations are not committed as well, because of this
>> phenomenon.
>>
>> We use TopLink inside Eclipse RCP with RESOURCE_LOCAL configuration.
>>
>> Any thoughts, or ideas, what causes this phenomenon? We are using the
>> current TopLink Essentials version,
>>
>> thank you in advance,
>>
>> adam bien
>>
>>
>
>
> -----
> ---
> http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
> http://www.oracle.com/technology/products/ias/toplink/ Oracle TopLink ,
> http://www.eclipse.org/eclipselink/
> EclipseLink , https://glassfish.dev.java.net/javaee5/persistence/ TopLink
> Essentials
> Wiki: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence ,
> http://wiki.eclipse.org/EclipseLink EclipseLink
> Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
> http://www.nabble.com/EclipseLink-f26430.html EclipseLink ,
> http://www.nabble.com/java.net---glassfish-persistence-f13455.html Glassfish
> Persistence
>
--
Consultant, Author, Java Champion
Homepage: www.adam-bien.com
Weblog: blog.adam-bien.com
eMail: abien_at_adam-bien.com
Mobile: 0049(0)170 280 3144
Books: Enterprise Architekturen (ISBN: 393504299X),
Java EE 5 Architekturen (ISBN: 3939084247),
J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and Struts