Jim,
I'm pretty sure that WL is pessimistic. I have seen it locking access to
TX_SERIALIZABLE entity beans. I'm with you on the testing. I think it
would be fun. You want to post some simple test code and a simple db table
description?
>From: James Cook <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Serialized Access
>Date: Wed, 12 Jul 2000 10:36:39 -0400
>
>I am longing for some of the more meaningful discourses that this group was
>famous for before EJB became the technology de jour. ;-)
>
>I know that EJB development simplifies many of the aspects of producing
>distributed software. The most obvious plus is the transaction support.
>However, one of the more insidious problems with architecting distributed
>solutions is concurrency control. I am interested in finding out how some
>of
>the more popular app servers assist the developer in managing concurrency,
>particularly in respect to entity beans.
>
>I can start by mentioning the app server I am most familiar with, Inprise
>Application Server. This server does not serialize access to entity beans.
>If two clients want to work on the same entity bean, IAS will create two
>separate instances of the bean. Both clients can modify the bean
>simultaneously. All concurrency is pushed to the database. I suppose this
>can be best termed as an example of optimistic concurrency. This design
>promises high availability within the container, but causes the developer
>to
>carefully manage concurrency issues with the database. The developer has to
>ensure the db has not been modified since the last read.
>
>The opposite side of the coin is pessimistic concurrency. This is when the
>app server serializes access to the actual beans in the system. As long as
>a
>particular instance of an entity bean is involved in a transaction, no
>other
>client can start a new transaction on that bean. Obviously, there are
>tradeoffs in both systems, but pessimistic concurrency greatly simplifies
>the developer's responsibility while, most likely, sacrificing performance.
>
>How about these other web servers? What approaches do they use? Is weblogic
>and websphere pessimistic by nature? What are some solid approaches for
>reducing concurrency issues in an optimistic container especially when
>dealing with course objects?
>
>It's highly possible that we could develop a concurrency test for all EJB
>servers. If we have a simple table with an int column, we could write an
>EJB
>that increments this value by 1. After hitting the entity bean with
>multiple
>clients for an hour, we can verify concurrency by checking for any
>duplicate
>values. We could also compare the transactions per second easily.
>
>Fun stuff?
>jim
>
>===========================================================================
>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".
>
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
===========================================================================
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".
