transaction question 1

[Themuppeteer]

Hello,
Can anyone tell me what happens when you do the following thing in J2ee (in jboss for instance)

I have 2 session beans with the first a function f1 and second the function f2, each calling the same 2 entity beans.Each function runs in a transaction as usual in J2ee


f1()
{
a.changeIt();
b.changeIt();
}

f2()
{
b.changeIt();
a.changeIt();
}

f1 and f2 run at the same time.
a and b are entity beans.
Normally you would have a deadlock situation here.
Will a and b be locked from the start of the function ?
or will it just create the deadlock and then break it with an exception and rollback (so nothing will have happenned ?
What exactely will go on here ?


Thanks.

Greetz,

NOSPAM_themuppeteer@hotmail.com (for mails, remove the NOSPAM_)

http://www.themuppeteer.tk

"Those who say they understand chess, understand nothing"

-- Robert HUBNER

 

[sedj]

Well, possibly.

I'm sorry, I give up.

It seems as if *spec-compliant* EJB is geared to not letting non-container-managed synchronized transactions occur. The CriticalHelper solution would solve this problem. I'm sorry I know of no other way around this.

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[Themuppeteer]

Yes, we've already noticed that it is not easy to find solutions for several things (this one, speed of entity beans,the fact that non persistent field in entity beans are somehow forgotten after passivation etc..)

Wel, anyway, thanks for the discussion and the CriticalHelper idea. Might come in handy some day.





Greetz,

NOSPAM_themuppeteer@hotmail.com (for mails, remove the NOSPAM_)

http://www.themuppeteer.tk

"Those who say they understand chess, understand nothing"

-- Robert HUBNER

 

[Themuppeteer]

Hey, this might be a solution, lets do the a.changeit() and b.changeit() in a serializable transaction. Then the method does its stuff and everything else is on hold.


Ed Roman in Mastering ejb's page 314:


SERIALIZABLE
You can easily avoid phantoms (as well as the other problems described earlier)
by utilizing the strictest isolation level: SERIALIZABLE. SERIALIZABLE
guarantees that transactions execute serially with respect to each other, and it
enforces the isolation ACID property to its fullest. This means that each transaction
truly appears to be independent of the others.
When to Use SERIALIZABLE
Use SERIALIZABLE for mission-critical systems that absolutely must have
perfect transactional isolation. You are guaranteed that no data will be read
that has been uncommitted. You’ll be able to reread the same data again and
again. And mysterious committed data will not show up in your database
while you’re operating due to concurrent transactions.
Use this isolation level with care because serializability does have its cost. If all
of your operations execute in SERIALIZABLE mode, you will quickly see how
fast your database performance grinds to a halt. (A personal note: Because
transactional errors can be very difficult to detect, due to scheduling of
processes, variable throughput, and other issues, we subscribe to the view that
it’s better to be safe than sorry.)



Greetz,

NOSPAM_themuppeteer@hotmail.com (for mails, remove the NOSPAM_)

http://www.themuppeteer.tk

"Those who say they understand chess, understand nothing"

-- Robert HUBNER