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
