Hi Bill, all,
Bill Burke wrote:
> All,
>
> We have the following (bad?) assumption in our application code:
>
> ----------------------------
> begin transaction
>
> Bean b = findByPrimaryKey(...)
> System.out.println("flag = " + b.getFlag()); // prints flag = 1
> b.setFlag("0")
>
> Enumeration = findByAllBeansWithFlagEqualToOne(....) // where flag = '1'
>
> // We assume Bean b is not in the Enumeration, but it is.
>
> end transaction
> ----------------------------
>
> My question to you guys is,
>
> Should storeEntity be called after every Entity method invocation? Right
> now, a database update only happens when the Entity is commited. What
does
> the spec say on this? I can't find anything at the moment.
As of my experience with i.e. Oracle your assumption is ok, changes
done inside an open transaction should be seen by queries done in
the very same transaction, although not committed. (And I think,
this is ANSI/XOpen too).
Searching the EJB specs (1.1) I didn't find any similar
statement (have spent an hour and hit over 50 more/less related
places).
But synch to the DB seems to be VERY expensive just to find back
what's already in the cache, and then possibly to be rolled back,
isn't it?
EJB 1.1 seems to ignore this issue at all, the most interesting
places are quoted Žbelow. From 9.4.2, adapted to your scenario,
I assume, that the spec sucks: you would evenly expect to see
freshly created beans in your TX, but that section allows deferring
the insert 'to the end of the transaction'.
A better solution to this seems to have finders work on the
EJB server instead of the persistence store, respecting
transactions? But the spec doesn't allow it. (?)
Hmmm, am I babbling rubbish? Sorry to be too tired to continue.
best regards as usual
Georg
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
Quotes from the spec:
9.1.7
| The container invokes the ejbStore method at the end of a
| transaction, and may also invoke it at other times when the
| instance is in the ready state. (For example the container may
| invoke ejbStore when passivating an instance in the middle of a
| transaction, or when transferring the instance's state to another
| instance to support distributed transactions in a multi-process
| server.)
9.1.4, somewhere in the middle
| The purpose of the ejbLoad and ejbStore methods is to synchronize
| the state of the instance with the state of the entity in the
| underlying data source - the container can invoke these methods
| whenever it determines a need to synchronize the instance's
| state.
9.1.6, in the middle
| The container must invoke this method on the instance whenever it
| becomes necessary for the instance to synchronize its state in
| the database with the state of the instance's fields. This
| synchronization always happens at the end of a transaction.
| However, the container may also invoke this method when it
| passivates the instance in the middle of a transaction, or when
| it needs to transfer the most recent state of the entity object
| to another instance for the same entity object in the same
| transaction (see Subsection 11.7).
9.4.2, near end
| The container may create the representation of the entity in the
| database immediately after ejbCreate(...) returns, or it can
| defer it to a later time (for example to the time after the
| matching ejbPostCreate(...) has been called, or to the end of the
| transaction).
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
