If I am running in READ_COMMITTED isolation, then the only guarantee that I 
have is that each individual SQL query I issue will run over a consistent view 
of the database, with no outstanding work to be committed.  Changes may be 
committed between queries.

So I could sum up the gross and nett weight on a load of order lines with the 
statement

SELECT SUM(nett_weight), SUM(gross_weight) FROM order_lines WHERE....

Now if I use an ejb finder to retrieve the instances

SELECT OBJECT(o) from OrderLine WHERE ...

One query is used to get the list of ids.

Now as I read through the returned collection and load the state of each 
object, a new query is issued to the database to load the state of the object.

The problem is that as I read through the returned order lines, another 
transaction may have committed changes on the lines I haven't read yet (still 
satisfying the conditions of read committed), and I am working with inconstent 
data.

If I was working with Hibernate or manual JDBC, I at least have the option to 
do everything in one query.   With the fundamental way that ejb finders work, I 
cannot do that, and run far greater risk of working on inconsistent data.

Is this analysis correct?

View the original post : 
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3861950#3861950

Reply to the post : 
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3861950


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to