Thanks for your answer, the thing is I want to avoid loading the entity bean
to find out if the version is incorrect.
I'm throwing an exception if the sql update fails - ModifiedException. But
can't catch the exception in the Session bean.
Exception in SessAdminOdpBean.generateOdp: Unable to commit,
tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=PC114//67, BranchQual=]
status=STATUS_NO_TRANSACTION; - nested throwable:
(framework.util.ModifiedException: RdbEntOdp.update: record not updated)
We're using XA. Any ideas?
Thanks,
PS
----- Original Message -----
From: "Sergiu Truta" <[EMAIL PROTECTED]>
To: "Pablo Schor" <[EMAIL PROTECTED]>
Sent: Friday, January 16, 2004 12:17 PM
Subject: Re: BMP/T, optimistic locking and trying to revert a commit
>
> First of all you should call rollback in each catch (from the code snippet
> you have showed us), in case there is any problem, the transaction should
> roll back.
> In the case you have described, you said that "when the session bean
> commits, the container executes ejbLoad - wich fails when the version is
> incorrect." If there is no exception thrown and the transaction is not
> rolled back than you should do something before the commit in order for
the
> container to try and load the bean. In this way if the version is
different
> that an exception will be thrown before the commit happens and in the
> corresponding catch you can rollback the transaction.
>
> Best regards,
> Sergiu Truta.
>
> ----- Original Message -----
> From: "Pablo Schor" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, January 16, 2004 4:59 PM
> Subject: Re: BMP/T, optimistic locking and trying to revert a commit
>
>
> > I can't, Evan, since I've already commited the transaction. The code in
> the
> > session bean goes like this:
> >
> > UserTransaction ut = null;
> > try {
> > BMPDataBean dataBean = getHome().findByPrimaryKey( pk );
> > ut = m_context.getUserTransaction();
> > ut.begin();
> > dataBean.setXXX ( xxx );
> > dataBean.setYYY ( yyy );
> > ut.commit();
> > }
> > catch (EJBException e) {
> > e.printStackTrace();
> > }
> > catch (NamingException e) {
> > e.printStackTrace();
> > }
> > catch (Exception e) {
> > e.printStackTrace();
> > }
> >
> >
> >
> > The thing is when the session bean commits, the container executes
> ejbLoad -
> > wich fails when the version is incorrect.
> >
> > Throwing EJBException doesn't prevent the commit. I need the commit to
> fail
> > under some circumstances, I jus't don't find the way to make it fail.
> >
> > PS
> >
> >
> >
> > ----- Original Message -----
> > From: "Evan Ireland" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, January 14, 2004 8:00 PM
> > Subject: Re: BMP/T, optimistic locking and trying to revert a commit
> >
> >
> > > Throw an EJBException from EJBStore. Catch the exception in the SB
> > > and call rollback, then retry.
> > >
> > > > -----Original Message-----
> > > > From: A mailing list for Enterprise JavaBeans development
> > > > [mailto:[EMAIL PROTECTED] Behalf Of Pablo Schor
> > > > Sent: Thursday, 15 January 2004 11:35 a.m.
> > > > To: [EMAIL PROTECTED]
> > > > Subject: BMP/T, optimistic locking and trying to revert a commit
> > > >
> > > >
> > > > I have the following situation: Jboss 3.2.1, one statless
> > > > session bean, one BMP entity beans. The session bean updates the
> > > > table through _BMT_, but the ejbStore has a "version=v" in the
> > > > where clause and if it fails (no rows updated), it has to throw
> > > > an exception to the session bean.
> > > >
> > > >
> > > > The container executes the ejbStore() method when the session
> > > > bean issues a commit, but if the version is incorrect, the BMP
> > > > throws an exception - trying to rollback since the update clause
> > > > didn't update the required row.
> > > >
> > > >
> > > > Questions:
> > > >
> > > > 1. What Exception should the BMP throw? Can a BMP throw an
> > > > application specific exception? if not, how can the BMP notify
> > > > the session bean the fact no rows were updated?
> > > > 2. In any case, can the commit be reverted?
> > > >
> > > >
> > > > Thanks for any info,
> > > > PS
> > > >
> > > >
> > > > ==================================================================
> > > > =========
> > > > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > > > in the body
> > > > of the message "signoff EJB-INTEREST". For general help, send email
> to
> > > > [EMAIL PROTECTED] and include in the body of the message "help".
> > > >
> > > >
> > >
> > >
> >
>
===========================================================================
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > > of the message "signoff EJB-INTEREST". For general help, send email
to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
