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?
This is due to the short transaction model. For the most time a client
is not in a transaction at all. Only when they call a bean method do they
start a transaction. During the time they were not inside a transaction,
rows could have been updated and thus they can re-update those rows with
stale data.
Frank Sauer
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Floyd Marinescu
> Sent: Saturday, September 16, 2000 1:51 PM
> To: [EMAIL PROTECTED]
> Subject: does TX_serializeable imply write lock, TX_repeatable_read
> imply readlock?
>
>
> 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".
>
===========================================================================
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".
