I don't believe I ever positioned the "synchronized" customization as "the"
solution. If it came across that way, my apologies; it was not my
intention.
I would be happy to have synchronized gets and sets as the first step toward
a larger and more helpful solution (of sub-tree locking).
Also, I believe that the provider (whether the RI or some other one) should
eventually do all that it can to provide something like sub-tree locking,
since it controls the generation of the content classes. It is therefore
much easier for the JAXB provider to handle such object capabilities during
generation, rather than for the client to have to come up with solutions
on a case-by-case basis (see my previous post concerning sub-tree locking
for what I'm talking about).
As far as difficulty, I did not mean that it could not be done at all.
I simply meant that using something like:
synchronized (object1) {
synchronized (object2) {
synchronized (object3) {
...
}
}
}
... is not the way to approach sub-tree locking. Those are the
built-in synchronization techniques that I was talking about.
Non-standard techniques would involve more complex lock objects,
such as might be provided in the concurrency utils package by Doug Lea
in 1.5.
Anyway, to summarize:
1) synchronized gets and sets would be a helpful first step
to solve the finest-grained thread safety
2) sub-tree locking could come further down the road, as far as
I'm concerned, but should probably have most of its
functionality generated by the JAXB provider
Thanks, as always, for your time and attention,
Brian Franklin
-----Original Message-----
From: Kohsuke Kawaguchi [mailto:Kohsuke.Kawaguchi_at_Sun.COM]
Sent: Friday, April 25, 2003 1:00 PM
To: JAXB-INTEREST_at_JAVA.SUN.COM
Subject: Re: Binding customization for "synchronized"
> Sub-tree locking is probably extremely difficult, if not impossible, to
> achieve using standard or built-in synchronization techniques
No. I think it's just difficult for the JAXB RI to do it. Application
developers can invent whatever way that suites them, and those are not
necessarily complicated. It's just that there's no "one-size-fits-all"
solution.
I think I'm just objecting to position the <xjc:synchronized />
customization as "the" solution to the synchronization issue. Since
adding that functionality is not so hard, I *personally* don't have any
problem in adding that feature.
So if we could find a nice way to expose it that sets the proper
expectation for users, that would be great.
regards,
--
Kohsuke KAWAGUCHI 408-276-7063 (x17063)
Sun Microsystems kohsuke.kawaguchi_at_sun.com