I will post the other issues separately.
As far as which case is the common case, I can't really say, having only
come across my case so far. However, I can definitely understand that
the sub-tree you mentioned is the bigger or more generalized case, of which
my synchronization issues are seemingly a subset. That said, I would be
happy to shift the discussion thread to that issue instead.
Sub-tree locking is probably extremely difficult, if not impossible, to
achieve using standard or built-in synchronization techniques
(i.e. using the synchronized keyword to obtain an object's monitor) because
of several factors:
1) The block structure of the synchronized keyword.
2) The fact that multiple monitors would have to be obtained in
a way that would minimize, if not eliminate, the possibility
of deadlocks when trying to obtain those monitors.
3) The fact that a child object could be contained in multiple
parents.
I see two ways in which sub-tree locking could be achieved. The first way
is what I believe you were talking about before (correct me if I'm wrong),
where the locking is done on a case-by-case basis using lock objects
external
to the schema-derived classes. I consider this a sort of workaround,
or less than ideal. The primary problem with this technique is that
it's not very automatic. The client code would have to have a different
lock object for every sub-tree for which it wanted to provide thread-safe
locking.
The more automatic solution would be to have every schema-derived class
contain a Lock object (that might follow an interface similar to that
specified in java.util.concurrent.Lock, found at
http://gee.cs.oswego.edu/dl/concurrent/dist/docs/index.html ).
Each content class would then have a lock() and release() method, which
would acquire or release the locks for all children using their
lock() and release() methods. There might be ways to pass a Lock object
back to the client code, so that it can access the Lock methods directly,
but this might require a special Lock class for each content class,
customized for its child properties.
This starts to resemble row- or record-level locking in a relational
database,
and certainly performance would suffer at least slightly; however, the
functional and ease-of-use gains would be phenomenal in a multi-threaded
environment. This could still be turned on or off, I would think,
by a global binding customization.
I realize I didn't put in a lot (or any) examples in this post, and I hope
what I wrote above makes at least some sense without them, but I would be
happy to elaborate on or hypothesize some examples of how
it might work if you would like to explore this issue further in an
open forum such as this.
As always, thanks for your time and consideration of this issue,
Brian Franklin
-----Original Message-----
From: Kohsuke Kawaguchi [mailto:Kohsuke.Kawaguchi_at_Sun.COM]
Sent: Thursday, April 24, 2003 10:55 AM
To: JAXB-INTEREST_at_JAVA.SUN.COM
Subject: Re: Binding customization for "synchronized"
> There were others that I considered higher-priority or more interesting.
I'd be interested in hearing them, too. And thank you for the elaborated
post.
> Approach 3 would be used in cases where complex properties, like lists and
> such, did need that extra level of external synchronization, but there
> would be an obvious lock object to use--the configuration object itself.
The case I had in my mind is where I'd like to lock a complete sub-tree
or some region of the content tree, not just one object with its
attached properties. If you could look at the recent XML&XSD posted from
Russell Johns, I'd like to lock the entire <executableInfo> section when
I'm letting one thread to modify it, for example. And to me, that is the
common case.
regards,
--
Kohsuke KAWAGUCHI 408-276-7063 (x17063)
Sun Microsystems kohsuke.kawaguchi_at_sun.com