• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

EJB transaction issue

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am having an issue with EJB transactions (regradless of BMT or CMT).
If i have a say a bean which has the following methods

interface_meth1() - (method in remore interface) - Transaction attribute is 'Not Supports'.
{
get db connection (say conn) from connection pool //step 1
Call interface_meth2(conn) //step 2 (passing the db connection is step 1
(Please note that i do a local look up of the same bean for invoking interface_meth2)
}

interface_meth2(Connection conn) - Transaction attribute is Required (methd in local interface)
{
insert //step 3
update //step 4
insert //step 5
}

If step 5 throws an exception, i see changes made by step 4 commited in the database. if however i open a db connection within interface_meth2 it works fine. (I am using WL 9.2 and while setting uo the data source has selected 'Enable Two phase commit'). Is this expected behaviour? Can somebody help?

Thanks
 
g Ven
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I probably logged this in the wrong forum. I apologize. Is there someway i can move it to the right forum?
 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's because when you are calling the interface_meth2 (without the lookup) it's just a java method call. The transaction is not started by the container when you do so. Hence any exceptions that occur later on, will not rollback the update since the update was not part of the transaction.

Now, when you do a lookup and invoke the method, it works because the update becomes part of the transaction and any exception within the transaction scope will rollback the update.
 
g Ven
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just wanted to clarify, I am making the local call to the ejb using a lookup (thru the local interface). The scenario really is:

1> lookup connection object from Pool
2> Start a transaction (by calling a method whose transaction attribute is Required/Required New - i tried setting both)
3> Issue a series of updates/inserts
4> Roll back

I am printing the transaction status as well after rollback and it is 'Marked for rollback'.

If i recreate the same scenario with the exception that step 1 (which is lookup of connection object) is after step 2 (start of transaction) then, it rolls back just fine.

So, the question is, am i missing anything here? I hava a clear requirement to use the same connection object prior to start of transaction.

Thanks
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
meth1's tx attribute is NotSupported ,so meth2's tx will not be started

you can refer to J2EE specification as follows:

NotSupported

If the client is running within a transaction and invokes the enterprise bean's method, the container suspends the client's transaction before invoking the method. After the method has completed, the container resumes the client's transaction.

If the client is not associated with a transaction, the container does not start a new transaction before running the method.

Use the NotSupported attribute for methods that don't need transactions. Because transactions involve overhead, this attribute may improve performance.
 
Ranch Hand
Posts: 368
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by g Ven:
Just wanted to clarify, I am making the local call to the ejb using a lookup (thru the local interface). The scenario really is:

1> lookup connection object from Pool
2> Start a transaction (by calling a method whose transaction attribute is Required/Required New - i tried setting both)
3> Issue a series of updates/inserts
4> Roll back

I am printing the transaction status as well after rollback and it is 'Marked for rollback'.

If i recreate the same scenario with the exception that step 1 (which is lookup of connection object) is after step 2 (start of transaction) then, it rolls back just fine.

So, the question is, am i missing anything here? I hava a clear requirement to use the same connection object prior to start of transaction.

Thanks


Going through the steps you mentioned, I see that you are doing the lookup for connection pool before starting the transaction. Because of this, your connection is not a managed resource in the transaction and the transaction rollback does not roll back the sql you did on the database through the connection.
For this to work fine, its necessary that your connection is a managed resource inside the transaction and for this you need to lookup for it inside the transaction. Maybe the code below explains better:
Wrong Code

Correct Code
 
Maybe he went home and went to bed. And took this tiny ad with him:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic