This will still have the same problem. The issue is the way JMX works vs. the way Terracotta works. JMX access will go through the MBeanServer and it never allows you to get an actual handle on the object. Instead, you can use reflection or get a proxy object. Additionally, JConsole will connect to the MBeanServer to do different operations. The JMX code and JConsole will never use the Map to access the objects and thus will never access a lock. I think this means I need to use a named lock or an auto-lock with auto-syncronzied=true and do this for all our MBean methods. Does this sound correct, or is there a better way?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geert Bevin Sent: Friday, December 07, 2007 10:28 AM To: [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [tc-dev] [tc-users] global lock level How about using ConcurrentHashMap instead? On 07 Dec 2007, at 19:15, Jason Chaffee wrote: > 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-users mailing list > [EMAIL PROTECTED] > http://lists.terracotta.org/mailman/listinfo/tc-users -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ 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
