On Sun, Jun 22, 2008 at 10:28 PM, Andrus Adamchik
<andru..bjectstyle.org> wrote:
>
> On Jun 20, 2008, at 10:41 PM, Øyvind Harboe wrote:
>
>> - the JavaDoc explained *why* the synchronization is there and what it
>> is supposed to do and how the client is supposed to use it.
>
> From the class JavaDocs: "A synchronized list that serves as a container of
> DataObjects"... A Collection is either synchronized or not. No other
> explanation is needed.
That's what I thought, until I saw this construct:
someList.subList(a,b).clear();
a) what does the above do?
b) is it broken if it requires synchronisation?
It is possible to implement a list such that the above does not require
the caller to be aware whether or not synchronisation is required.
> Now regarding the synchronization scope, my current POV (that is somewhat
> different from my past opinion) is that the list methods should NOT be
> synchronized by default
Glad to hear this. :-)
> (i.e. users should create synchronized wrappers if
> they need to). This way IncrementalFaultList will be aligned with standard
> Java collections. One thing that still must be synchronized internally is
> the DB operations to avoid multiple concurrent fetches of the same data.
> This does not require synchronization of most normal list access methods.
Is the synchronisation mechanism for IncrementalFaultList required for this
purpose?
I.e. does the *implementation* require it even if the caller does not? I didn't
find any evidence of that.
> I.e. the scope of synchronization should be significantly reduced. (We can
> do something extra fancy with syncing DB ops per page to allow parallel page
> faulting, but that's certainly not a very high priority task).
>
> Now your mention of performance issues... My guess without looking at the
> code, this is unlikely to happen due to oversynchronization. Compared to
> other things that are going on, synchronization overhead should be
> negligible. Of course running in profiler should answer that for sure.
The performance problem would arise if multiple CPUs where blocking on access
to the same list. Obviously multiple CPUs would have to work on *different*
data not to require synchronisation. At that point the synchronisation
mechanism no longer serves any purpose.
My point is simply that the synchronisation code in IncrementalFaultList
does not help the user nor does it make the code any clearer + it is potentially
broken anyway.
Is it tested?
Code that isn't tested, doesn't work. Murphys law.
Code that is tested, doesn't necessarily work either. Murphys law.
The only difference between the two is that code that isn't tested, is
guaranteed not to work. If you spend the time to write the code that
tests it, you've wasted the time because it then works. Murphys law.
The only way you can win is if you delete the code. :-)
> Finally thanks for opening CAY-1075. One request - could you submit any code
> as patches instead of full files - it will make it much easier to analyze
> the changes.
Once I have something useful, I'll create the patch. For now I use Jira as
a file store. The way I work is simply to copy & paste the Cayenne .java
file into my app and fetch the rest from Cayenne. I don't actually compile
Cayenne when I hack it.
-- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer
This archive was generated by hypermail 2.0.0 : Mon Jun 23 2008 - 02:44:13 EDT