hi felix,
On 4/21/06, Felix Satyaputra <[EMAIL PROTECTED]> wrote:
> Hi Stefan,
>
>
> > the .lock file has nothing to do with it. it just
> > prevents
> > multiple RepositoryImpl instantiation using the same
> > configuration.
> I see.
>
> > write operations on the persistence layer are
> > synchronized
> > on a higher level in order to guarantee data
> > consistency/
> > referential integrity (e.g. node references).
> >
> > see SharedItemStateManager#begin, #end and #cancel
> > methods.
> I've checked SharedItemStateManager#begin, #end and
> #cancel.
>
> So basically SharedItemStateManager manages the
> concurrency of the read/write operations by using the
> ReadWriteLock - within the same thread? I notice that
> the ReadWriteLock is being used in #begin, #end, and
> #cancel.
concurrent read operations are allowed if there's no current
write operation or if the reading and writing thread are
identical.
code snippet from SharedItemStateManager:
/**
* Read-/Write-Lock to synchronize access on this item state manager.
*/
private final ReadWriteLock rwLock =
new ReentrantWriterPreferenceReadWriteLock() {
/**
* Allow reader when there is no active writer, or current
* thread owns the write lock (reentrant).
*/
protected boolean allowReader() {
return activeWriter_ == null
|| activeWriter_ == Thread.currentThread();
}
};
>
> Am I understanding this correctly? So it's not the
> PersistenceManager's responsibility to manage the
> concurrency of the read/write operation?
correct.
cheers
stefan
>
> Cheers,
>
> Felix
>
> Send instant messages to your online friends http://uk.messenger.yahoo.com
>
