I think I might have an issue afterall. Let's assume that I have Map that is my root that contains all of the MBeans. There is sync code around access to the Map. The problem is that we use JConsole to edit the MBeans and JConsole will not acess the MBeans through the Map, where the lock is placed. This implies that I would need locks on each MBean and this brings me back to my original concern. Does anyone see a better solution?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kunal Bhasin Sent: Thursday, December 06, 2007 11:05 PM To: [EMAIL PROTECTED]; [email protected] Subject: Re: [tc-users] [tc-dev] global lock level Yeah, all mutations to shared objects need to happen under the scope of some lock. So, when the access to the Map is protected by locks, you are essentially saying: Acquire Lock <------ Scope of Lock starts Obj o = map.get(); or map.put(o); Release Lock <------ Scope of Lock ends Now if you try o.setSomething(newValue); (I am assuming setSomething(Object newValue) is not synchronized or protected by a lock). The shared object o is being mutated without any locking. Hence you see the exception and this is the expected behavior. So, depending on your requirements, you might want to do something like: Acquire Lock <------ Scope of Lock starts Obj o = map.get(); map.setSomething(newValue); Release Lock <------ Scope of Lock ends This would be perfectly legal. I think the main pain point you are experiencing is the amount of work required to configure all the locking (am I correct?). If you haven't already, please take a look at the Annotations TIM (Terracotta Integrations Module) which will make this task more manageable. Secondly, like others have pointed out before, using concurrent locking is almost always not a good idea. If you are certain that only one thread is going to mutate objects at a time, note that in that case the write lock will be local (greedy). JDK 1.5 onwards, the locking overhead is really minimal. I wanted to point this out even though you have mentioned that performance is not a concern here. The main reason not to use concurrent locks is to maintain data coherence. A concurrent lock means NO Distributed Lock and there are no transactional guarantees around propagating the changes. For example, thread1 makes a change to someObject. Of course, you are interested in clustering because some other thread (say thread2) in another JVM should be able to see the changes just made by thread1 in a timely fashion (the first time it reads AFTER the write lock has been released). In this case, if thread1 makes the change under the scope of a concurrent lock, you don't get guarantees around when thread2 on JVM2 will get these changes. The read thread might have read the older value AFTER the change was made. Keep in mind that this is identical to the way the JVM memory model works i.e. if you did the same thing (mutations without locking) with multiple threads in a single JVM without Terracotta, you will get the same behavior. Makes sense? Kunal. On 12/6/07 10:18 PM, "Alex Miller" <[EMAIL PROTECTED]> wrote: > UnlockedSharedObjectException perhaps? > > That usually indicates that you have not specified that synchronized block to > be a clustered lock in the tc-config.xml. The easiest way to do that is > usually by declaring it as auto-synchronized locking for that method. There > are other options (named locks, or even locks based on annotations) but that's > usually the easiest. You can set the concurrency level for > read/write/concurrent as appropriate when accessing the Map. > > On UnlockedSharedObjectException, see: > http://www.terracotta.org/confluence/display/wiki/Troubleshooting+Guide# Troubl > eshootingGuide-Iamgettingcom.tc.object.tx.UnlockedSharedObjectException. Whatne > xt%3F > > On locking, see: > http://www.terracotta.org/confluence/display/docs1/Configuration+Guide+a nd+Ref > erence#ConfigurationGuideandReference-%2Ftc%3Atcconfig%2Fapplication%2Fd so%2Fl > ocks > http://www.terracotta.org/confluence/display/docs1/Concept+and+Architect ure+Gu > ide#ConceptandArchitectureGuide-locks > http://www.terracotta.org/confluence/display/docs1/Locking+Guide > > > > ----- Original Message ----- > From: "Jason Chaffee" <[EMAIL PROTECTED]> > To: [email protected] > Cc: [EMAIL PROTECTED] > Sent: Thursday, December 6, 2007 11:43:27 PM (GMT-0600) America/Chicago > Subject: Re: [tc-dev] [tc-users] global lock level > > During a demo done by a colleague, there was an object inside the Map > and access to the Map was synchronized. However, Terracotta gave an > error specify that a certain method in the object needed to be > synchronized. Am I missing something here or perhaps my colleague made > a mistake? > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Alex Miller > Sent: Thursday, December 06, 2007 9:38 PM > To: [email protected] > Cc: [email protected]; [EMAIL PROTECTED] > Subject: Re: [tc-dev] [tc-users] global lock level > > I think the key point is that clustered locks need to be specified only > when touching clustered state (shared objects). Usually the shared data > structure is fairly contained and accessed through a pretty narrow set > of paths, and hence distributed locking needs to be defined only on > those narrow paths. > > So, for example, say you had a cache of user information stored in a > HashMap and the HashMap was shared. You need to perform clustered > locking only when accessing the HashMap (get/put/etc) or when accessing > objects in the HashMap (the User object maybe). > > Or put another way, clustered locking occurs only when you do > synchronized(sharedObject). > > > ----- Original Message ----- > From: "Jason Chaffee" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [email protected] > Sent: Thursday, December 6, 2007 11:23:45 PM (GMT-0600) America/Chicago > Subject: Re: [tc-dev] [tc-users] global lock level > > I am not sure I totally grasp what you mean by: > > > > Worth noting I think that adding auto-locking on classes of instances > that aren't ever shared has no impact. Distributed locks only occur when > a shared object is locked on. So the number of locks one generally needs > is usually small. > > > > Would it be possible to get some elaboration or see a brief example? > Maybe I am just being dumb because of the long day....:) > > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > > _______________________________________________ > tc-users mailing list > [EMAIL PROTECTED] > http://lists.terracotta.org/mailman/listinfo/tc-users Kunal Bhasin | ------------------------------------------------ Professional Services Engineer Terracotta Inc. | San Francisco Ca 650 773 9544 (C) | 415 738 4049 (O) ------------------------------------------------ Terracotta Confidentiality Policy: http://www.terracottatech.com/emailconfidentiality.shtml _______________________________________________ tc-users mailing list [EMAIL PROTECTED] http://lists.terracotta.org/mailman/listinfo/tc-users _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
