Hi there,
today I think I've encountered very similar problem. In my case, it
looks like this:
(srcLoanTxWorker and dstLoanTxWorker are stateful session beans)
@Stateful
public class TxAmountTransferBean implements TxAmountTransferRemote {
@EJB private LoanTxWorkerRemote srcLoanTxWorker;
@EJB private LoanTxWorkerRemote dstLoanTxWorker;
public void init(long srcTxId, long dstLoanId, BigDecimal transferAmount) {
Transaction srcTx = ...;
BigDecimal srcTxAmount = ...;
BigDecimal newSrcTxAmount = ...;
srcLoanTxWorker.init(srcTx.getLoanId());
srcLoanTxWorker.modifyAmount(srcTxId, newSrcTxAmount);
srcLoanTxWorker.execute();
dstLoanTxWorker.init(dstLoanId);
Transaction newTxTemplate = ...'
dstLoanTxWorker.insertNewTx(newTxTemplate);
dstLoanTxWorker.execute();
}
public void save(String defaultDocNo) {
dstLoanTxWorker.save(defaultDocNo); //this is @Remove method
srcLoanTxWorker.save(defaultDocNo); //this is @Remove method
}
}
What happens is when calling TxAmountTransferBean's save method it calls:
(1) dstLoanTxWorker.save(defaultDocNo);
(2) srcLoanTxWorker.save(defaultDocNo);
And (2) always throws an exception:
EJB5018: An exception was thrown during an ejb invocation on [LoanTxWorkerBean]
javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
Id does not matter if I swap (1) and (2) - always the second in row
throws above exception. For me it looks exactly as your case, where
Glassfish, due to some bug, aborts transaction, so it cannot call (2)
successfully as it does require transaction...
Did you report an issue about that on GlassFish community page? Looks
like a serious bug to me... Tomorrow I will try your workaround, I
mean I will add new method
@Remove
@TransactionAttribute(TransactionAttributeType.NEVER)
public void remove() { }
and I will change sequence to be like this:
public void save(String defaultDocNo) {
dstLoanTxWorker.save(defaultDocNo);
srcLoanTxWorker.save(defaultDocNo);
dstLoanTxWorker.remove(); // now this is @Remove method
srcLoanTxWorker.remove(); // now this is @Remove method
}
I hope it is going to work, because I am in troubles otherwise :/
Regards,
Witold Szczerba
2007/10/31, glassfish_at_javadesktop.org <glassfish_at_javadesktop.org>:
> Thanks for your follow-up. I use the following architecture:
>
> Application 1:
> - StructureSessionBean
>
> Application 2:
> - CollectorSessionBean
>
> StructureSessionBean calls CollectorSessionBean using the InitialContext object. So far, so good. But the CollectorSessionBean also calls the StructureSessionBean to make so backward changes (using the InitialContext again). Maybe the error has to do with the fact that both beans reside in different applications?
>
> Anyhow, when I annotate the @Remove methods with the NEVER transactiontype, then everything seems to function. I cannot create a sample directly now to reproduce the error. But I'll see what I can do.
>
> Thanks
> Jan
> [Message sent by forum member 'ossaert' (ossaert)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243049
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>