Jonathan,
Could you explain how you (or Sybase) implement (i)? I do know how the appserver could
implement the repeatable read isolation level, but I'd like to hear how you implement
serializable.
-----
Peter Verkest
---------------------------------------- Message History
----------------------------------------
From: "Jonathan K. Weedon" <[EMAIL PROTECTED]>@JAVA.SUN.COM> on 10.07.2001 10:19 MST
Please respond to [EMAIL PROTECTED]
DELEGATED - Sent by: A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Serializable isolation level (RE: [EJB-INT] To scale or to be
correct: that is the question)
"Zetie, Carl" wrote:
> Now I have a question for the list (if anybody is still reading!) When
> people write that VendorX app server CMP "implements" serializable isolation
> by default, do they mean (i) that the CMP is actually checking for update
> conflicts, (ii) that the CMP is verifying that the database is implementing
> serializable isolation for this transaction, or (iii) that the CMP /assumes/
> that the database is serializing the tx and therefore is actually doing /no/
> verification itself.
Carl,
Yes, when Evan said that Sybase implements serializable isolation by default,
he meant (i) "that the CMP [engine] is actually checking for update conflicts".
In Borland AppServer, this is not the default behavior (which Krishnan
complained about) but is an optional behavior. In WebLogic, this is not a
supported behavior (at least not with EJB 1.1, although Cedric amusingly
suggested that customers can rewrite their applications using EJB 2.0 if they
need this functionality in WebLogic.) In WebLogic, case (iii) holds: "the
CMP [engine] /assumes/ that the database is serializing the tx and therefore
is actually doing /no/ verification itself."
I am not aware of a product that does (ii). I would argue that (ii) is a currently
a burden on the deployer when using (iii). That is, if the CMP engine is assuming
that the database is doing the serialization, then it is up to the deployer to ensure
that the database is configured appropriately.
Which is an interesting point unto itself. I am willing to bet that a very large
percentage of EJB applications are not configured correctly with respect to
serialization (that is, the default serialization is used from the appserver and
from the database). If you are using anything other than Sybase's appserver,
you will therefore be subject to "stomping" updates, using this default
configuration. Which motivates Krishnan's suggestion that appserver-based
verification be the default behavior, since we can't reasonably convince
Oracle to make serializable be the default transaction isolation (due to the
performance overhead).
-jkw
===========================================================================
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".
--
Diese E-Mail enth�lt vertrauliche und/oder rechtlich gesch�tzte Informationen. Wenn
Sie nicht der richtige Adressat sind oder diese E-Mail irrt�mlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorised copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
==========================================================================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".
