> 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).
Hey Floyd,
Hmm. I don't think this is the case. At least in Oracle, it's not
really a locking issue at all. It's more complicated.
Read this:
http://technet.oracle.com/doc/oracle8i_816/server.816/a76965/c23cnsis.htm
(you'll have to sign up for Oracle's technet)
A quote:
"Because Oracle does not use read locks in either read-consistent or
serializable transactions, data read by one transaction can be overwritten
by another. Transactions that perform database consistency checks at the
application level should not assume that the data they read will remain
unchanged during the execution of the transaction even though such changes
are not visible to the transaction. Database inconsistencies can result
unless such application-level consistency checks are coded with this in
mind, even when using serializable transactions. "
So people's concerns are valid. Weird, but true.
If I can sum up what the issue is, it is this:
When a serializable or repeatable read txn reads some data, the data is
virtually put into a snapshot that can be looked at again while the
transaction is running. If another transaction interferes (writes over) the
data in the virtual snapshot, then commits, everything is still cool (it's
as if one transaction ran, then the other - it's "serialized"). If the
first txn tries to update data the second transaction updated, then it gets
rolled back.
Michael Bushe
Bushe Enterprises, Inc.
Enterprise Java Consultant
[EMAIL PROTECTED]
www.bushe.com
508-497-2367
>
> 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".
