jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Database PersistenceManagers (was "Results of a JR Oracle test that we conducted)
Date Mon, 12 Mar 2007 15:52:16 GMT
Jukka Zitting wrote:
>> A) a change log must be persisted as a whole or not at all
>> I) while a change log is persisted a read must not see partially 
>> stored content
> 
> These could both be achieved also with connection pooling, just
> acquire a connection at the beginning of PersistenceManager.store()
> and commit the changes at the end of the method before releasing the
> connection.
> 
> Similar pattern would also work for all the load() and exists()
> methods to avoid the need to synchronize things on the prepared
> statements.

Agreed.

>> C) this is actually handled by the upper level
> 
> ACK, the key is the write lock on SharedItemStateManager. In fact, do
> we even need the database persistence managers to be transactional
> over multiple method calls?

I can't follow you here. what exactly do you mean by weakening transaction 
requirements on the persistence manager? e.g. reading of uncommitted items?

> And to follow, could we in fact already
> now remove the synchronization of read operations given that
> consistency is already achieved on a higher level?

yes, we can. the persistence manager just has to ensure that only committed data 
is returned.

regards
  marcel

Mime
View raw message