I just got the Gemstone CD yesterday. I'll look at some of their
documentation.
BTW, I wasn't specifically looking for a solution for myself. I am hoping to
encapsulate many approaches in this thread to benefit all of the list
subscribers by making them think about the problem. Too often we take EJB
for granted as an end all to our real life development solutions. There is
still much to contemplate.
thanks,
jim
----- Original Message -----
From: Hussman, David <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 12, 2000 11:45 AM
Subject: Re: Serialized Access
> Jim,
>
> I agree with the sentiment of your email. Have you looked at the Gemstone
> white papers for J2EE success? They have addressed many of the nasty
> implementation and design issues in a thorough and thought provoking
manner.
> Anyone know of any other deep thinking ejb design white papers or other
> docs?
>
> -----Original Message-----
> From: James Cook [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 12, 2000 9:37 AM
> To: [EMAIL PROTECTED]
> Subject: 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".
>
===========================================================================
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".
