Re: BMP/T, optimistic locking and trying to revert a commit

Vineeth Varghese <[email protected]>
Newsgroups gmane.comp.java.sun.ejb.general
Message-ID <[email protected]>
Hi Folks,

I have been watching this thread for sometime and got a doubt here.

Pablo mentioned that the ejbLoad is executed after the commit...I may be
wrong but I am not aware about any such requirement in the spec. Isn't
this container spec..

Pablo which container are you using?

Cheerio,
Vineeth.

Pablo Schor wrote:

>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]]On 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".
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.