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".
