Pablo, i guess you missed my point;
The spec (ejb 2.0 fr sec. 17.3.1 paragraph 3) says entity beans must always use container managed transactions: "An Entity Bean must always be designed with container-managed transaction demarcation." The fact that you have a bussiness object (session bean) where you demarcate where the transaction begins and ends does not change this. itīs still the container that tells the entity which is its transactional context. so setting EntityContext.setRollBackOnly() will indicate to your UserTransaction that the transaction may only be rolled back because the container has previously set the transactional context to ut. This will set the ut status to rollback-only, which is what you want, not committing the transaction. Sven -----Original Message----- From: Pablo Schor [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 12:59 PM To: [EMAIL PROTECTED] Subject: Re: BMP/T, optimistic locking and trying to revert a commit Sven, if you need more control on the transaction flow you can use BMT. I understand your idea, but I'm trying to avoid loading the entity just to see if the version is different - since I can obtain the quantity of updated rows in the sql update. Making fail the commit with an exception thrown within ejbStore and catching the exception in the session bean would do the job, but apparently I'd end up loading the entity again. Thanks for your answer, PS ----- Original Message ----- From: "sven van't veer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 16, 2004 1:26 PM Subject: Re: BMP/T, optimistic locking and trying to revert a commit > fwiw > > I donīt work much with BMT but AFIK, Entity beans MUST ALWAYS work with container managed transactions, so, if you set EntityContext.setRollBackOnly() when version!=v or whatever condition you have there, the transaction in whose context this entity performs the update will never commit. > > Sven > -----Original Message----- > From: Pablo Schor [mailto:[EMAIL PROTECTED] > Sent: Friday, January 16, 2004 12:00 PM > To: [EMAIL PROTECTED] > 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". > > > > this message contains information that may be privileged and confidential. unauthorized use, disclosure, dissemination and/or copying are strictly prohibited. if you are not the intended recipient, please delete this message and any attachments and notify us immediately. please do not copy this message or disclose its contents to anyone. thank you. > > > > =========================================================================== 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". this message contains information that may be privileged and confidential. unauthorized use, disclosure, dissemination and/or copying are strictly prohibited. if you are not the intended recipient, please delete this message and any attachments and notify us immediately. please do not copy this message or disclose its contents to anyone. thank you.
