Hi Krishnan, You're definitely preaching to the choir; I mentioned what's needed to implement cluster-pessimistic-locking in order to demonstrate its difficulty. However, I disagree with your statement that "boosting performance is one of the primary reasons why you are clustering in the first place". Clustering improves scalability of multiple requests and reliability/failover of individual requests, but will almost always decrease the performance of individual requests simply due to the intrinsic cluster overhead.
To boost performance on a cluster environment, many solutions have been offered, including Dimitri's Seppuku pattern and Lawrence's (my former coworker at Kiko) SmartCache posted on theserverside.com. And let me also plug my friend Cameron's Tangosol Coherent Replicated Cache (http://www.tangosol.com/products-clustering.jsp). The fact there are so many offered solutions demonstrate the scope of this problem: cluster-caching for performance is the holy grail of J2EE! Gene --- Krishnan Subramanian <[EMAIL PROTECTED]> wrote: > Gene, > > Building a correct model for pessimistic locking is non-trivial > (to say the least!) in a clustered environment. > > Pessimistic locking [in the AppServer] as I mentioned earlier is > quite inefficient and also unscalable. The technique you mention > might actually solve the problem, but the overhead of using such > a solution will probably outweigh any performance benefit. (Boosting > performance is one of the primary reasons why you are clustering > in the first place!). In my personal opinion, avoid AppServer > pessimistic locking like the plague. > > One of the reasons I mentioned this was because there are a lot > of projects in production out there, and awareness of such a > problem might be low. (I believe you mentioned in a recent posting > on theserverside.com about how things were dragged down by Session > Bean --> Entity Bean communication due to the incorrect transaction > attributes being used). > > -krish > > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans development > > [mailto:[EMAIL PROTECTED]]On Behalf Of Gene Chuang > > Sent: Friday, December 21, 2001 11:58 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Concurrent access of entity object > > > > > > In order for cluster pessimistic locking to work properly, a node needs to send >out a > > sychronous multicast message declaring lock on an entity bean even prior to issuing > > update multicasts. And these messages have to be both synchronous and >rollback-able. > > > > --- John Harby <[EMAIL PROTECTED]> wrote: > > > I've seen some (non-J2EE) clustering scenarios where say - > > > the web server(s) reside on a different host(s) and is/are smart > > > enough to multicast db write requests to all members of the > > > app server cluster. This allows all participants to be aware of > > > the transaction graph control the tx accordingly. > > > > > > > > > >From: Krishnan Subramanian <[EMAIL PROTECTED]> > > > >Reply-To: Krishnan Subramanian <[EMAIL PROTECTED]> > > > >To: [EMAIL PROTECTED] > > > >Subject: Re: Concurrent access of entity object > > > >Date: Thu, 20 Dec 2001 12:58:41 +0100 > > > > > > > >Suresh Babu, > > > > > > > >Are you talking about pessimistic concurrency at the > > > >AppServer level - that is, serializing access to a single > > > >entity bean instance as an attempt to solve the problems > > > >arising out of concurrent access to entity beans? > > > > > > > >If so, there is no (easy) solution for this problem when the > > > >AppServer is clustered. > > > > > > > >As an analogy, you have a single pipe (your AppServer) > > > >to something (your database) as an attempt to control > > > >everything. But the moment you start adding a second > > > >pipe (a second AppServer) to that same something or > > > >a third or more, then things are going out of control. This > > > >is not an exact analogy (so do not beat me over the head > > > >with it ;) - but it is sufficient to explain the problem. > > > >A single pipe can only handle so much before shallowing > > > >out (in terms of performance). > > > > > > > >-krish > > > > > > > > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > > > > > > =========================================================================== > > > 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". > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Send your FREE holiday greetings online! > > http://greetings.yahoo.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". > > > > > > =========================================================================== > 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". > __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.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".
