I have some comments for Tomas in-lined below > > -----Message d'origine----- > De : Tomas Lapienis [mailto:[EMAIL PROTECTED]] > Envoyé : samedi, 10 novembre 2001 14:57 > À : Sacha Labourey > Objet : Fw: [JBoss-dev] Clustering is available for use > > > Hi Sacha, > > It's still not clear for me how you lock EB > ("We use pessimistic locking at the database level") > when database does not support this? >
IMHO, you're a fool if you're writing a large distributed system with concurrent access problems with a database that doesn't support locking. Why would you use such a database for these types of systems? If it doesn't support locking, then it definately hasn't been designed to scale to distributed applications. > What happens when (can it happen?) > ClientA gets access to ClusterNodeA SessionBeanA > ClientB gets access to ClusterNodeB SessionBeanB > > and SessionBeanA loads EB's X and Y > and SessionBeanB loads EB's Y and Z > > and (with money) subtracts $5 from X and adds to Y > and (with money) subtracts $7 from Y and adds to Z > > will EB Y be mutually exclusive for both transactions > at the app server (JBoss) when database does not > support SELECT FOR UPDATE style locking? > Let's look at this problem from a different direction. What if you were using just straight JDBC? What would you do then? You could set your TransactionIsolation level from READ_COMMITTED to SERIALIZED if your DB didn't support locking. You can define the TransactionIsolation level on DataSource pools in JBoss. Then you'll say "What if the DB doesn't support SERIALIZED isolation level?". Then I'll answer again. Why are you using this DBMS for what it wasn't meant to do? > Just in case when answer is no... > I was trying to say that it would be nice to > have load balanced EB's living on specific cluster node > identified by hash value from PK. > Let's say > EB X and Z lives on ClusterNodeA > Y lives on ClusterNodeB > > so SB A will call X local and Y remote > and SB B will call Y local and Z remote > > EB's XYZ will participate on 2 distributed transactions > with necessary locking stuff... > IMHO, you want to always have collocated calls no matter what. When bean instances live on different nodes you're just asking for performance, synchronization, and scalability problems. You are also required to have a Distributed Transaction Manager. > Performance should not decrease significantly, > because the data caching is taking place. > I guess there is no big difference (sometimes it is, of course) > either to load EB from database > or to load EB from another cluster node (cluster node is known well, > because EB's are spreaded among nodes based on their pk hash value) > I want to keep the base clustering design as simple as possible. I want people to be able to look at the code and know how it works instantly so that they can plug-in funky features like distributed locking and such. BTW, Entity-Bean locking is pluggable anyways, so one could write a distributed locking/caching mechanism if they really wanted. > I guess that commit-option 'B' does not work > (when locking transactions are needed) when > database does not support select for update style locking... > So I just played another scenario here and am asking > if this scenario is or will be valid for JBoss usage... > Hope I didn't sound rude above. I just feel very passionate about how locking should be delegated to your DBMS. > Sorry for long letter This is a good discussion for people to participate in IMHO Bill _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
