Phil Shrimpton wrote:

> On Friday 14 November 2003 09:15, Adrian Brock wrote:
>
> Hi,
>
>
>>>JBoss 3.2.2, Commit Option A...
>>>
>>>I have a SLSB method something like...
>>>
>>>public void doSomething(){
>>>   Collection c = OrdersEJB.getItems();
>>>   <loop through collection and do some calculations>
>>>   <delete one of the 'items'>
>>>}
>>>
>>>If these method is called at the same time by two different clients, the
>>>first one works the second gives me an error
>>>
>>>2003-11-13 16:38:49,707 ERROR [org.jboss.ejb.plugins.LogInterceptor]
>>>TransactionRolledbackLocalException in method: public abstract
>>>java.sql.Date
>>>com.prometricssoftware.CHaS2.ejb.core.diaryqueue.QueueLocal.getActionDate
>>>(), causedBy:
>>>javax.ejb.NoSuchObjectLocalException: Entity not found: primaryKey=102
>>>
>>>..now if I switch to Commit Option B for the 'item' EJB, I don't get this
>>>error, and all seems to work as I expect it to.
>>
>>Under option A, it does the getItems() against the db.
>>But the actual iteration/load is done against the cache.
>
>
> Just to make sure I understand, with Commit A the finder is querying the DB,
> which contains a 'record' that has been deleted from the cache, but not from
> the DB,

No. When remove is called on an instance, the synchronization occurs.
The case you described should not be possible.

Are the clients accessing different orders which have common items? And
then one of the common items is removed?

> and when I am doing the iteration the entity has already been deleted
> from the cache and I get the (uncatchable) NoSuchObjectLocalException?
>
> If so, is not Commit option A dangerous, ith something beaing read from the
> (up to date) cache, and others being read from the (out of date) DB?
>
>
>>Under option B, it will recheck the db (a load) before the delete
>>because B cannot assume the db is in synch across transactions.
>
>
> I understand how this works, because everything is read from the same place
>
>
>>To avoid the problem in general, you need "repeatable read" isolation
>>which wouldn't work with commit option A/JBoss's Queued pessimistic
>>lock anyway.
>
>
> So basically, from what I understand, is Commit Option A has problems if you
> are deleting 'records'? I am not sure that is right?

No, it should not.

>
> Phil




-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
JBoss-user mailing list
JBoss-user@(protected)
https://lists.sourceforge.net/lists/listinfo/jboss-user