You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Jencks <da...@yahoo.com> on 2011/02/22 22:37:47 UTC
exposing exceptions that caused a rollback
cf
https://issues.apache.org/jira/browse/GERONIMO-4576
https://issues.apache.org/jira/browse/OPENEJB-1091
For a long time we've known of this problem where an exception thrown by a transaction synchronization that causes a transaction to be marked for rollback only is lost. When the user or openejb tries to commit the transaction the transaction manager throws a RollbackException which currently doesn't have any information about the original exception.
People have complained about this for a long time.... now we're trying to fix it.
There are two parts AFAICT. I think in openejb we just need to take the TransactionRolledBackException we are currently throwing and call initCause with the RollbackException from the tm. In TransactionPolicy this would be something like
} catch (RollbackException e) {
txLogger.info("The transaction has been rolled back rather than commited: " + e.getMessage());
// TODO can't set initCause on a TransactionRolledbackException, update the convertException and related code to handle something else
Throwable txe = new javax.transaction.TransactionRolledbackException("Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: "+e.getMessage());
-- throw new ApplicationException(txe);
++ throw new ApplicationException(txe.initCause(e);
In the transaction implementation we need to keep track of the exception that caused us to mark rollback only and then use it as the cause of the RollbackException, e.g.
private Exception markRollbackCause;
...
RollbackException rollbackException = new RollbackException("Unable to commit: transaction marked for rollback");
if (markRollbackCause != null) {
rollbackException.initCause(markRollbackCause);
}
throw rollbackException;
...
private void markRollbackCause(Exception e) {
if (markRollbackCause == null) {
markRollbackCause = e;
}
}
(this tm code is committed in rev 1073479 in my sandbox tm)
At the moment if a sync throws an exception, we keep calling the other syncs, and it would be possible for other ways of marking rollback only due to an exception to occur more than once as well. So there's a question as to whether we should only record the first cause of rollback only or if we should keep track of a list of causes. The code above only tracks the first cause. I'm really not sure what to think about this and would appreciate comments.
Thoughts?
thanks
david jencks
p.s. "we" includes Ashish Jain and David Blevins and possibly others.... we finally got moving on this due to a customer complaint. Better late than never :-)
Re: exposing exceptions that caused a rollback
Posted by Ashish Jain <as...@gmail.com>.
Hi Djencks/Dblevins,
As we had discussed earlier about this issue and the possible patch. It
seems we cannot use javax.transaction.
TransactionRolledbackException.initCause(e) instead there is another class
with in openEJB
org.apache.openejb.core.transaction.TransactionRolledbackException which can
be utilized. So can we go ahead
and use this exception class. Are there any reasons why we had not used this
class earlier?
For your reference
have a look at line no 146 in the class
https://svn.apache.org/repos/asf/openejb/tags/openejb-3.0.3/container/openejb-core/src/main/java/org/apache/openejb/core/transaction/TransactionPolicy.java
Once I use this class I see better logging however it stills seems
incomplete. What can we do to get more logging in this case?
Snippets of log from my eclipse when I run the client
Caused by: java.lang.Exception: Transaction has timed out
at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:261)
... 18 more
Snippets of log from my geronimo.log
2011-02-24 14:35:50,625 DEBUG [OpenEJB] finished invoking method create.
Return
value:proxy=com.test.ibm.TestTransactionInterface;deployment=test4/TestTransaction;pk=205efedb35aa1fff:ef95222:12e56ea419b:-7fe4
2011-02-24 14:35:50,640 DEBUG [jndi] JNDI REQUEST:
JNDI_LOOKUP:null:TestTransactionRemote -- RESPONSE:
JNDI_BUSINESS_OBJECT:STATEFUL:test4/TestTransaction:com.test.ibm.TestTransactionInterface:205efedb35aa1fff:ef95222:12e56ea419b:-7fe4
2011-02-24 14:35:50,718 INFO [Transaction] TX RequiresNew: Suspended
transaction null
2011-02-24 14:35:50,718 INFO [Transaction] TX RequiresNew: Started
transaction org.apache.geronimo.transaction.manager.TransactionImpl@f5472d
2011-02-24 14:35:50,750 INFO [Runtime] Starting OpenJPA 1.2.2
2011-02-24 14:35:50,843 INFO [JDBC] Using dictionary class
"org.apache.openjpa.jdbc.sql.DerbyDictionary" (Apache Derby 10.5.3.0 -
(802917) ,Apache Derby Embedded JDBC Driver 10.5.3.0 - (802917)).
2011-02-24 14:36:02,015 INFO [Transaction] TX RequiresNew: Committing
transaction org.apache.geronimo.transaction.manager.TransactionImpl@f5472d
2011-02-24 14:36:02,109 INFO [Transaction] The transaction has been rolled
back rather than commited: Unable to commit: transaction marked for rollback
2011-02-24 14:36:02,109 INFO [Transaction] TX RequiresNew: No transaction
to resume
2011-02-24 14:36:02,109 DEBUG [ejb] EJB REQUEST:
EJB_OBJECT.BUSINESS_METHOD:test4/TestTransaction:firstMethod:205efedb35aa1fff:ef95222:12e56ea419b:-7fe4
-- RESPONSE:
EJB_APP_EXCEPTION:org.apache.openejb.core.transaction.TransactionRolledbackException:
Transaction was rolled back, presumably because setRollbackOnly was called
during a synchronization: Unable to commit: transaction marked for rollback
Thanks
Ashish
On Thu, Feb 24, 2011 at 9:26 AM, David Jencks <da...@yahoo.com>wrote:
>
> On Feb 23, 2011, at 7:35 PM, Kevan Miller wrote:
>
> >
> > On Feb 22, 2011, at 4:37 PM, David Jencks wrote:
> >
> >> cf
> >> https://issues.apache.org/jira/browse/GERONIMO-4576
> >> https://issues.apache.org/jira/browse/OPENEJB-1091
> >>
> >> For a long time we've known of this problem where an exception thrown by
> a transaction synchronization that causes a transaction to be marked for
> rollback only is lost. When the user or openejb tries to commit the
> transaction the transaction manager throws a RollbackException which
> currently doesn't have any information about the original exception.
> >>
> >> People have complained about this for a long time.... now we're trying
> to fix it.
> >>
> >> There are two parts AFAICT. I think in openejb we just need to take the
> TransactionRolledBackException we are currently throwing and call initCause
> with the RollbackException from the tm. In TransactionPolicy this would be
> something like
> >>
> >> } catch (RollbackException e) {
> >>
> >> txLogger.info("The transaction has been rolled back rather
> than commited: " + e.getMessage());
> >> // TODO can't set initCause on a
> TransactionRolledbackException, update the convertException and related code
> to handle something else
> >> Throwable txe = new
> javax.transaction.TransactionRolledbackException("Transaction was rolled
> back, presumably because setRollbackOnly was called during a
> synchronization: "+e.getMessage());
> >> -- throw new ApplicationException(txe);
> >> ++ throw new ApplicationException(txe.initCause(e);
> >>
> >> In the transaction implementation we need to keep track of the exception
> that caused us to mark rollback only and then use it as the cause of the
> RollbackException, e.g.
> >>
> >> private Exception markRollbackCause;
> >>
> >> ...
> >> RollbackException rollbackException = new RollbackException("Unable to
> commit: transaction marked for rollback");
> >> if (markRollbackCause != null) {
> >> rollbackException.initCause(markRollbackCause);
> >> }
> >> throw rollbackException;
> >>
> >> ...
> >>
> >> private void markRollbackCause(Exception e) {
> >> if (markRollbackCause == null) {
> >> markRollbackCause = e;
> >> }
> >> }
> >>
> >> (this tm code is committed in rev 1073479 in my sandbox tm)
> >>
> >> At the moment if a sync throws an exception, we keep calling the other
> syncs, and it would be possible for other ways of marking rollback only due
> to an exception to occur more than once as well. So there's a question as
> to whether we should only record the first cause of rollback only or if we
> should keep track of a list of causes. The code above only tracks the first
> cause. I'm really not sure what to think about this and would appreciate
> comments.
> >>
> >> Thoughts?
> >
> > Great to get more data captured. So, I'm all for it...
> >
> > Personally, I would think the *first* cause will almost always be the
> most important information a user would want... Any situations where
> subsequent exceptions are going to yield valuable information? Or will they
> mostly generate noise?
>
> Well, since the known cause of this problem is openjpa flushes during the
> tx syncs, it would be entirely possible to have more than one if there is
> more than one persistence unit/persistence context involved in the
> transaction. So I'd guess it's quite uncommon but entirely possible. It's
> probably only an hour or so more work to implement something for more
> exception, dunno how much testing we'd want to do.
>
> I don't know if there are likely to be additional "side effect" exceptions
> caused by a particular exception. Offhand I can't think of any.
>
> thanks
> david jencks
>
> >
> > --kevan
>
>
Re: exposing exceptions that caused a rollback
Posted by Ashish Jain <as...@gmail.com>.
Hi Djencks/Dblevins,
As we had discussed earlier about this issue and the possible patch. It
seems we cannot use javax.transaction.
TransactionRolledbackException.initCause(e) instead there is another class
with in openEJB
org.apache.openejb.core.transaction.TransactionRolledbackException which can
be utilized. So can we go ahead
and use this exception class. Are there any reasons why we had not used this
class earlier?
For your reference
have a look at line no 146 in the class
https://svn.apache.org/repos/asf/openejb/tags/openejb-3.0.3/container/openejb-core/src/main/java/org/apache/openejb/core/transaction/TransactionPolicy.java
Once I use this class I see better logging however it stills seems
incomplete. What can we do to get more logging in this case?
Snippets of log from my eclipse when I run the client
Caused by: java.lang.Exception: Transaction has timed out
at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:261)
... 18 more
Snippets of log from my geronimo.log
2011-02-24 14:35:50,625 DEBUG [OpenEJB] finished invoking method create.
Return
value:proxy=com.test.ibm.TestTransactionInterface;deployment=test4/TestTransaction;pk=205efedb35aa1fff:ef95222:12e56ea419b:-7fe4
2011-02-24 14:35:50,640 DEBUG [jndi] JNDI REQUEST:
JNDI_LOOKUP:null:TestTransactionRemote -- RESPONSE:
JNDI_BUSINESS_OBJECT:STATEFUL:test4/TestTransaction:com.test.ibm.TestTransactionInterface:205efedb35aa1fff:ef95222:12e56ea419b:-7fe4
2011-02-24 14:35:50,718 INFO [Transaction] TX RequiresNew: Suspended
transaction null
2011-02-24 14:35:50,718 INFO [Transaction] TX RequiresNew: Started
transaction org.apache.geronimo.transaction.manager.TransactionImpl@f5472d
2011-02-24 14:35:50,750 INFO [Runtime] Starting OpenJPA 1.2.2
2011-02-24 14:35:50,843 INFO [JDBC] Using dictionary class
"org.apache.openjpa.jdbc.sql.DerbyDictionary" (Apache Derby 10.5.3.0 -
(802917) ,Apache Derby Embedded JDBC Driver 10.5.3.0 - (802917)).
2011-02-24 14:36:02,015 INFO [Transaction] TX RequiresNew: Committing
transaction org.apache.geronimo.transaction.manager.TransactionImpl@f5472d
2011-02-24 14:36:02,109 INFO [Transaction] The transaction has been rolled
back rather than commited: Unable to commit: transaction marked for rollback
2011-02-24 14:36:02,109 INFO [Transaction] TX RequiresNew: No transaction
to resume
2011-02-24 14:36:02,109 DEBUG [ejb] EJB REQUEST:
EJB_OBJECT.BUSINESS_METHOD:test4/TestTransaction:firstMethod:205efedb35aa1fff:ef95222:12e56ea419b:-7fe4
-- RESPONSE:
EJB_APP_EXCEPTION:org.apache.openejb.core.transaction.TransactionRolledbackException:
Transaction was rolled back, presumably because setRollbackOnly was called
during a synchronization: Unable to commit: transaction marked for rollback
Thanks
Ashish
On Thu, Feb 24, 2011 at 9:26 AM, David Jencks <da...@yahoo.com>wrote:
>
> On Feb 23, 2011, at 7:35 PM, Kevan Miller wrote:
>
> >
> > On Feb 22, 2011, at 4:37 PM, David Jencks wrote:
> >
> >> cf
> >> https://issues.apache.org/jira/browse/GERONIMO-4576
> >> https://issues.apache.org/jira/browse/OPENEJB-1091
> >>
> >> For a long time we've known of this problem where an exception thrown by
> a transaction synchronization that causes a transaction to be marked for
> rollback only is lost. When the user or openejb tries to commit the
> transaction the transaction manager throws a RollbackException which
> currently doesn't have any information about the original exception.
> >>
> >> People have complained about this for a long time.... now we're trying
> to fix it.
> >>
> >> There are two parts AFAICT. I think in openejb we just need to take the
> TransactionRolledBackException we are currently throwing and call initCause
> with the RollbackException from the tm. In TransactionPolicy this would be
> something like
> >>
> >> } catch (RollbackException e) {
> >>
> >> txLogger.info("The transaction has been rolled back rather
> than commited: " + e.getMessage());
> >> // TODO can't set initCause on a
> TransactionRolledbackException, update the convertException and related code
> to handle something else
> >> Throwable txe = new
> javax.transaction.TransactionRolledbackException("Transaction was rolled
> back, presumably because setRollbackOnly was called during a
> synchronization: "+e.getMessage());
> >> -- throw new ApplicationException(txe);
> >> ++ throw new ApplicationException(txe.initCause(e);
> >>
> >> In the transaction implementation we need to keep track of the exception
> that caused us to mark rollback only and then use it as the cause of the
> RollbackException, e.g.
> >>
> >> private Exception markRollbackCause;
> >>
> >> ...
> >> RollbackException rollbackException = new RollbackException("Unable to
> commit: transaction marked for rollback");
> >> if (markRollbackCause != null) {
> >> rollbackException.initCause(markRollbackCause);
> >> }
> >> throw rollbackException;
> >>
> >> ...
> >>
> >> private void markRollbackCause(Exception e) {
> >> if (markRollbackCause == null) {
> >> markRollbackCause = e;
> >> }
> >> }
> >>
> >> (this tm code is committed in rev 1073479 in my sandbox tm)
> >>
> >> At the moment if a sync throws an exception, we keep calling the other
> syncs, and it would be possible for other ways of marking rollback only due
> to an exception to occur more than once as well. So there's a question as
> to whether we should only record the first cause of rollback only or if we
> should keep track of a list of causes. The code above only tracks the first
> cause. I'm really not sure what to think about this and would appreciate
> comments.
> >>
> >> Thoughts?
> >
> > Great to get more data captured. So, I'm all for it...
> >
> > Personally, I would think the *first* cause will almost always be the
> most important information a user would want... Any situations where
> subsequent exceptions are going to yield valuable information? Or will they
> mostly generate noise?
>
> Well, since the known cause of this problem is openjpa flushes during the
> tx syncs, it would be entirely possible to have more than one if there is
> more than one persistence unit/persistence context involved in the
> transaction. So I'd guess it's quite uncommon but entirely possible. It's
> probably only an hour or so more work to implement something for more
> exception, dunno how much testing we'd want to do.
>
> I don't know if there are likely to be additional "side effect" exceptions
> caused by a particular exception. Offhand I can't think of any.
>
> thanks
> david jencks
>
> >
> > --kevan
>
>
Re: exposing exceptions that caused a rollback
Posted by David Jencks <da...@yahoo.com>.
On Feb 23, 2011, at 7:35 PM, Kevan Miller wrote:
>
> On Feb 22, 2011, at 4:37 PM, David Jencks wrote:
>
>> cf
>> https://issues.apache.org/jira/browse/GERONIMO-4576
>> https://issues.apache.org/jira/browse/OPENEJB-1091
>>
>> For a long time we've known of this problem where an exception thrown by a transaction synchronization that causes a transaction to be marked for rollback only is lost. When the user or openejb tries to commit the transaction the transaction manager throws a RollbackException which currently doesn't have any information about the original exception.
>>
>> People have complained about this for a long time.... now we're trying to fix it.
>>
>> There are two parts AFAICT. I think in openejb we just need to take the TransactionRolledBackException we are currently throwing and call initCause with the RollbackException from the tm. In TransactionPolicy this would be something like
>>
>> } catch (RollbackException e) {
>>
>> txLogger.info("The transaction has been rolled back rather than commited: " + e.getMessage());
>> // TODO can't set initCause on a TransactionRolledbackException, update the convertException and related code to handle something else
>> Throwable txe = new javax.transaction.TransactionRolledbackException("Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: "+e.getMessage());
>> -- throw new ApplicationException(txe);
>> ++ throw new ApplicationException(txe.initCause(e);
>>
>> In the transaction implementation we need to keep track of the exception that caused us to mark rollback only and then use it as the cause of the RollbackException, e.g.
>>
>> private Exception markRollbackCause;
>>
>> ...
>> RollbackException rollbackException = new RollbackException("Unable to commit: transaction marked for rollback");
>> if (markRollbackCause != null) {
>> rollbackException.initCause(markRollbackCause);
>> }
>> throw rollbackException;
>>
>> ...
>>
>> private void markRollbackCause(Exception e) {
>> if (markRollbackCause == null) {
>> markRollbackCause = e;
>> }
>> }
>>
>> (this tm code is committed in rev 1073479 in my sandbox tm)
>>
>> At the moment if a sync throws an exception, we keep calling the other syncs, and it would be possible for other ways of marking rollback only due to an exception to occur more than once as well. So there's a question as to whether we should only record the first cause of rollback only or if we should keep track of a list of causes. The code above only tracks the first cause. I'm really not sure what to think about this and would appreciate comments.
>>
>> Thoughts?
>
> Great to get more data captured. So, I'm all for it...
>
> Personally, I would think the *first* cause will almost always be the most important information a user would want... Any situations where subsequent exceptions are going to yield valuable information? Or will they mostly generate noise?
Well, since the known cause of this problem is openjpa flushes during the tx syncs, it would be entirely possible to have more than one if there is more than one persistence unit/persistence context involved in the transaction. So I'd guess it's quite uncommon but entirely possible. It's probably only an hour or so more work to implement something for more exception, dunno how much testing we'd want to do.
I don't know if there are likely to be additional "side effect" exceptions caused by a particular exception. Offhand I can't think of any.
thanks
david jencks
>
> --kevan
Re: exposing exceptions that caused a rollback
Posted by Kevan Miller <ke...@gmail.com>.
On Feb 22, 2011, at 4:37 PM, David Jencks wrote:
> cf
> https://issues.apache.org/jira/browse/GERONIMO-4576
> https://issues.apache.org/jira/browse/OPENEJB-1091
>
> For a long time we've known of this problem where an exception thrown by a transaction synchronization that causes a transaction to be marked for rollback only is lost. When the user or openejb tries to commit the transaction the transaction manager throws a RollbackException which currently doesn't have any information about the original exception.
>
> People have complained about this for a long time.... now we're trying to fix it.
>
> There are two parts AFAICT. I think in openejb we just need to take the TransactionRolledBackException we are currently throwing and call initCause with the RollbackException from the tm. In TransactionPolicy this would be something like
>
> } catch (RollbackException e) {
>
> txLogger.info("The transaction has been rolled back rather than commited: " + e.getMessage());
> // TODO can't set initCause on a TransactionRolledbackException, update the convertException and related code to handle something else
> Throwable txe = new javax.transaction.TransactionRolledbackException("Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization: "+e.getMessage());
> -- throw new ApplicationException(txe);
> ++ throw new ApplicationException(txe.initCause(e);
>
> In the transaction implementation we need to keep track of the exception that caused us to mark rollback only and then use it as the cause of the RollbackException, e.g.
>
> private Exception markRollbackCause;
>
> ...
> RollbackException rollbackException = new RollbackException("Unable to commit: transaction marked for rollback");
> if (markRollbackCause != null) {
> rollbackException.initCause(markRollbackCause);
> }
> throw rollbackException;
>
> ...
>
> private void markRollbackCause(Exception e) {
> if (markRollbackCause == null) {
> markRollbackCause = e;
> }
> }
>
> (this tm code is committed in rev 1073479 in my sandbox tm)
>
> At the moment if a sync throws an exception, we keep calling the other syncs, and it would be possible for other ways of marking rollback only due to an exception to occur more than once as well. So there's a question as to whether we should only record the first cause of rollback only or if we should keep track of a list of causes. The code above only tracks the first cause. I'm really not sure what to think about this and would appreciate comments.
>
> Thoughts?
Great to get more data captured. So, I'm all for it...
Personally, I would think the *first* cause will almost always be the most important information a user would want... Any situations where subsequent exceptions are going to yield valuable information? Or will they mostly generate noise?
--kevan
Re: exposing exceptions that caused a rollback
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Hi,
No didn't get time to work on :-(
If you have time, feel free to push a patch file. I would be more than happy
to commit it for you.
Jean-Louis
--
View this message in context: http://openejb.979440.n4.nabble.com/exposing-exceptions-that-caused-a-rollback-tp3320089p3441821.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: exposing exceptions that caused a rollback
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
Posting the following message upon request by Ashish Jain as his posts are
getting rejected by mail server with reason spam score blah blah blah...
-----
Hi Jean-Louis,
It seems David has already applied a patch to GERONIMO-4576. IIUC OpenEJB
needs to be patched for OPENEJB-1091 so
that it works perfectly. Do you have a patch ready for this as I see David's
last comments that using the TransactionRolledBackLocalException may also
not fix this problem entirely.
Thanks
Ashish
-----
On Fri, Mar 4, 2011 at 2:51 AM, David Jencks <da...@yahoo.com> wrote:
> Hi Jean-Louis,
>
> I fixed up the 2.1.1 and later tm branches to include the fix so the
> RollbackException should now be including a reasonable cause.
>
> I assigned OPENEJB-1091 to you and added a few comments and a link to some
> mail. It would be really great if you have time to change openejb to "start
> with" the TransactionRolledBackLocalException and convert it to
> TransactionRolledBackException if necessary, but I don't think this is
> really needed just to get it to work.
>
> thanks!
> david jencks
>
> On Mar 3, 2011, at 6:31 AM, Jean-Louis MONTEIRO wrote:
>
> > Hi David,
> >
> > Discussed that point with Kevan on IRC.
> > It would be great if we could push that change. That's really something
> > users are always asking for.
> >
> > As soon as you have something ready and release, let us know. I would be
> > more than happy to change a bit OpenEJB to use the init cause.
> >
> > Thanks a lot.
> >
> > Jean-Louis
> >
> > --
> > View this message in context:
> http://openejb.979440.n4.nabble.com/exposing-exceptions-that-caused-a-rollback-tp3320089p3333444.html
> > Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
>
--
Vamsi
--------
SpeakAsiaOnline - Consumer Empowerment
Get your opinion heard and get paid too :)
http://www.speakasiaonline.com/
--------
Zero Budget Natural Farming - The future of Indian Agriculture
http://palekarzerobudgetnaturalfarming.com/
Re: exposing exceptions that caused a rollback
Posted by David Jencks <da...@yahoo.com>.
Hi Jean-Louis,
I fixed up the 2.1.1 and later tm branches to include the fix so the RollbackException should now be including a reasonable cause.
I assigned OPENEJB-1091 to you and added a few comments and a link to some mail. It would be really great if you have time to change openejb to "start with" the TransactionRolledBackLocalException and convert it to TransactionRolledBackException if necessary, but I don't think this is really needed just to get it to work.
thanks!
david jencks
On Mar 3, 2011, at 6:31 AM, Jean-Louis MONTEIRO wrote:
> Hi David,
>
> Discussed that point with Kevan on IRC.
> It would be great if we could push that change. That's really something
> users are always asking for.
>
> As soon as you have something ready and release, let us know. I would be
> more than happy to change a bit OpenEJB to use the init cause.
>
> Thanks a lot.
>
> Jean-Louis
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/exposing-exceptions-that-caused-a-rollback-tp3320089p3333444.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: exposing exceptions that caused a rollback
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Hi David,
Discussed that point with Kevan on IRC.
It would be great if we could push that change. That's really something
users are always asking for.
As soon as you have something ready and release, let us know. I would be
more than happy to change a bit OpenEJB to use the init cause.
Thanks a lot.
Jean-Louis
--
View this message in context: http://openejb.979440.n4.nabble.com/exposing-exceptions-that-caused-a-rollback-tp3320089p3333444.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.