Floyd,
The actual difference between a pessimistic lock and an optimistic lock is
whether the RDBMS does a physical lock (pessistic) or the app server uses a
logical locking scheme (optimistic). Therefore in an optimistic lock, there
is NO RDBMS lock meaning there can be multiple reads.
Local Diamons (what you called a colision) occur at isolation levels below
3. You could avoid these diamonds by using isolation level 3 but now you
will serialize the whole tx. Rather, let the container do its job as
mandated by the EJB 1.1 spec and detect the local diamond.
This only leaves the risk of a distributed diamond remaining.
Dave Wolf
Internet Applications Division
Sybase
> -----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".
