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.
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
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
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
