One thing I have am having trouble understanding is what exactly happens at
the databse level when a TX_Serializeable transaction reads some data.
As I understand it, TX_REPEATABLE_READ should force a read lock (so no one
can modify the rows you have just read until you are done), and
TX_SERIALIZEABLE should force a write lock (thus no one else can read or
write).
If this is so, then why are people on the EJB interest group saying that
you can have transactional "collisions" (two transactions read the same row,
then both update it, the second transaction updated with stale data) in app.
servers that use optimistic concurrency? Doesn't serializeable mean the
same thing whether your app. server uses pessimisstic or optimistic
concurrency?
So if one transaction reads a row in ejbLoad (and the calling transaction
is serializeable), then the database should force a write lock on this row.
If there is a write lock on this row, then there is no chance of another
transaction reading this row in ejbLoad until the current transaction is
done. So then how is it possible to have collisions?
Floyd
---------------------------------
Senior Architect / Director of Marketing
The Middleware Company
http://www.middleware-company.com
http://www.TheServerSide.com
[EMAIL PROTECTED]
416-889-6115
Check out TheServerSide.com, the internets first J2EE community!!!
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
