Problem with Committing a transaction

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

-- 
 Consultant, Author, Java Champion
 
 Homepage: www.adam-bien.com
 Weblog: blog.adam-bien.com
 eMail:  abienadam-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
   

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.eclips
e.org/eclipselink/
 EclipseLink ,  h
ttps://glassfish.dev.java.net/javaee5/persistence/
TopLink
Essentials 
Wiki:  http://
en.wikibooks.org/wiki/Java_Persistence Java Persistence
, 
http://wiki.eclip
se.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-per
sistence-f13455.html Glassfish
Persistence 
-- 
View this message in context: http://www.nabble.com/Proble
m-with-Committing-a-transaction-tf4643680.html#a13272227

Sent from the java.net - glassfish persistence mailing list
archive at Nabble.com.

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.eclips
e.org/eclipselink/
>  EclipseLink ,  h
ttps://glassfish.dev.java.net/javaee5/persistence/
TopLink
> Essentials 
> Wiki:  http://
en.wikibooks.org/wiki/Java_Persistence Java Persistence
, 
> http://wiki.eclip
se.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-per
sistence-f13455.html Glassfish
> Persistence 
>   


-- 
 Consultant, Author, Java Champion
 
 Homepage: www.adam-bien.com
 Weblog: blog.adam-bien.com
 eMail:  abienadam-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