Hello Tomas, Currently, we depend on the database for entity locking. So if the database doesn't support it, we can't handle it yet.
Check some information about databases here : http://www.geocrawler.com/archives/3/10766/2001/7/800/6253998/ If I remember well, it is also the way BEA Weblogic handles entity synchronization. There were some "interesting" discussions on EJB-interest a few times ago. As for your proposal, it would allow nice load-balancing but not failover. Any way, there are always some possible tricks to handle these specific cases. What is your database? Cheers, Sacha -----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? 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? 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... 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 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... Sorry for long letter Tomhia _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
