The thing to keep in mind is this is just java - so you can lock at whatever level you want - if you want to lock at the put level and not the bean level you can do that - you just need a lock active at the time you make the modification - how you acquire that lock is up to you but the point is it is just the same as protecting java objects lock in your setter, lock at the map.put or lock in the method that is updating the mbeans from the user/admin request.
On Dec 6, 2007, at 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#TroubleshootingGuide-Iamgettingcom.tc.object.tx.UnlockedSharedObjectException.Whatnext%3F > > On locking, see: > http://www.terracotta.org/confluence/display/docs1/Configuration+Guide+and+Reference#ConfigurationGuideandReference-%2Ftc%3Atcconfig%2Fapplication%2Fdso%2Flocks > http://www.terracotta.org/confluence/display/docs1/Concept+and+Architecture+Guide#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-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
