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
