It might be possible to simply just move the call to
pidLock.getWriteLock() up before the call to objectExists().
Then the first thread will get the lock and the second thread will be
rejected. Even if the first thread have released the writelock, then it
will have registered the object and the se
It's starting to sound like we need a pattern that is less constrictive of
resources than the use of "synchronized", but still maintains some kind of
guard against the kind of collision Jesper describes. A simpleminded thought:
perhaps we could insert a lightweight check against the registry bef
I just had a quick look at the code. As far as I can see (and I may not
be right) one problem may be the following:
Assume both threads with same PID are inside the method getIngestWriter
and has passed the method-call objectExists(...). At this point neither
of the objects exists assuming none of
Hi.
I originally opened the https://jira.duraspace.org/browse/FCREPO-1024
I tried back then to create tests in order to convince myself that there
would be no problems in removing the synchronization, but that proved
rather difficult.
As far as I remember there seemed to be some problems associa
There is a bit of history to this discussion:
https://jira.duraspace.org/browse/FCREPO-1024
---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Nov 6, 2012, at 11:53 AM, Scott Prater wrote:
> Nicolas,
>
> That's very encouraging... t
Nicolas,
That's very encouraging... this problem has been on my radar for years.
Not being very familiar with the details of the internals of DefaultDOManager,
I can't comment concretely on the merits of your patch, but I would be
especially interested in tests that provoke race conditions and
If I recall correctly, that method is synchronized so that a document
factory can be reused. We might be able to remove the synchronization if we
use the Templates class, I'll look into it. It is important to note that
having a single manager object increases the importance of guaranteeing
thread s
Hi,
I think I've found the main problem with massive parallel ingestion.
I'm working with the last github snapshot.
In org.fcrepo.server.storage.DefaultDOManager, the getIngestWriter method
should not be synchronized as it seems there is only a single instance of that
class for the server. The
