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
