I'm pretty sure that both WebSphere and WebLogic use pessimistic locking,
i.e. they serialize access to beans from different transactions. I consider
the only usable architecture with these servers is to have two levels of
transactions (altough whether the first one can be called a transaction is
arguable): The first level, which I call the logical transaction, will not
be related to the second level, the physical (JTS and/or DB) transactions.
With this model, the application will retrieve data from the entity bean
layer, using short, physical (JTS) transactions that are committed
immediately. The data in the session layer (either in the stateful session
beans or associated with the Servlet HTTP session) will then be a copy of
the data in the DB. Each change will be done against the copy, until finally
the logical transaction is "committed". This will result in a new (physical)
JTS transaction where all the updates are pushed into the entity bean layer.
When the physical transaction has been committed, the logical transaction
can be committed, too.
Of course in effect, this turns the pessimistic concurrency model used by
the app servers mentioned into an optimistic one at the application level,
so you have to do all the usual checks (by using a timestamp, a version
number or both in your DB).
Implementing a framework supporting this is not exactly easy, though,
because you have to be able to apply only the changes made to the copies to
the DB - i.e., you somehow need to record the history of objects that have
been updated, removed or inserted, not just the objects. Using a good
persistence framework will certainly help you here.
(One might argue that using long-lived JTS transactions that are "open" as
long as the user's logical unit of work lasts, are perfectly OK if you have
clear concept of object ownership. IMO, this assumption breaks down very
quickly when you consider the impact a large number of concurrent users will
have on the resource consumption in your app server and DB.)
____________________________________________________________________
Stefan Tilkov -- stefan(dot)tilkov(at)innoq(dot)com -- www.innoQ.com
> -----Urspr�ngliche Nachricht-----
> Von: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]Im Auftrag von James Cook
> Gesendet: Mittwoch, 12. Juli 2000 16:37
> An: [EMAIL PROTECTED]
> Betreff: Serialized Access
>
>
> 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".
>
>
===========================================================================
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".
