Yep, thanks! And I guess this is not JBoss specific behaviour but should
be the same in other servers also!?
/Lennart
Rickard �berg skrev:
>
> Hi!
>
> The implementation of this is in EntitySynchronizationInterceptor.java.
>
> Lennart Petersson wrote:
> > Reading the EJB 1.1 spec about exception handling and can't really
> > figure out what happens in a situation like this one:
> >
> > If an EntityBean (CMP) has changed some of its persistent fields but
> > then decides to throw an appl. exception (that is before any update in
> > db has been made), what happens with the changed fields in the bean
> > instance?
> >
> > Case 1: The tx is started in the EntityBean method and the method calls
> > on setRollbackOnly() before throwing the exception. I guess that the
> > container rollbacks the ongoing tx and rethrows the exception. The bean
> > instance in intact and can be used again. What about the fields?
>
> The instance will be sent back to the pool, i.e. next usage of entity
> will cause activation/load.
>
> > Case 2: Same as 1 but there is no call on setRollbackOnly(). Here i
> > guess that the container will attempt to commit the tx, the changed
> > fields will be stored in db, and then rethrows the exception. The bean
> > instance is intact and will have 'correct' field values. At least they
> > are the same as in db.
>
> Correct.
>
> > Case 3: The tx is already started by the caller and the caller retries
> > the call within the same tx. Here i guess that the container will
> > rethrow the exception to the caller. The bean instance is intact. The
> > caller calls the method again - but what value have the field then?
>
> The values they had when your instance threw the initial exception. The
> container will not do anything.
>
> > Case 4: Like 3 but the caller calls setRollbackOnly() and rethrows the
> > exception. Here i guess that the container will rollback the tx.
>
> Yes.
>
> > The
> > bean instance is intact. But what about the field values?
>
> They are considered stale and will be reloaded on next call.
>
> > Case 5: Like 3 but the caller just rethrows the exception without
> > calling setRollbackOnly(). Here i guess that the container will attempt
> > to commit the tx, the changed fields will be stored in db, and then
> > rethrows the exception. The bean instance is intact and will have
> > 'correct' field values like in case 2.
>
> Yes.
>
> > My problem: I'm really worried about what values the entity fields will
> > have, especially in the cases where the tx has been rolled back and no
> > update done in database! Do i have to manually reset the fields to its
> > originally value before throwing the appl. exception?
>
> As above, the instance will be sent back to the pool, and thus
> activated/*reloaded* on next usage.
>
> > Any comments to this rather basic EJB question? Maybe i'm stupid but for
> > the moment when i reads the spec i think that everything is a bit messy.
>
> Is it clearer now?
>
> /Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
mailto:[EMAIL PROTECTED]
http://www.benefit.se/english
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
