jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Google Summer of Code project for Jackrabbit
Date Fri, 26 May 2006 08:52:10 GMT
Nicolas Toper wrote:
> My issue is more: I save the ChangeLog object, but at the "real" commit
> time, an exception might still occur. How to handle it? Cf. in my last 
> mail:
> "I can even make persistant the modification using an already existing 
> PM in
> case of crash. One question though: I cannot guarantee the transaction 
> would
> be later committed without exception. We can choose to ignore this issue or
> add an asynchronous way to warn the session. What are your thoughts on 
> this?
> "

changes committed to a temp persistence manager during a backup should be 
moved to the primary persistence manager when:
1) the backup is completed
2) the system restarts after a crash that happened during a backup

In case of 2) the proxy pm should try to move the content from the temp to 
the primary and if at some point the transfer fails it should throw 
immediately an exception and prevent the repository from starting up. This 
way an admin can fix the problem (e.g. out of disk space) and try to start 
up the repository again. as miro already pointed out the transfer must be 
transactional as well to ensure that none or all data is moved from temp to 
primary.

> Would this strategy work? Another advantage of this strategy is: it might
> allow us later to add serializable transaction through a 2 phase locking 
> for
> instance (since we would have a layer to delay a transaction if needed).

I have to disappoint you on the 2PL capabilities of jackrabbit. the current 
design is entirely based on an optimistic approach. it's closely related to 
  what some people call 'backward-oriented optimistic concurrency control'. 
there are no lock tables in jackrabbit that a 2PL system usually has to 
maintain read and write locks (in a classic database sense).

wrt core changes, I think building a proxy persistence manager that exposes 
the backup facility through jmx or whatever is appropriate here, there is 
no need to change anything in the core. the proxy pm would simply implement 
the existing persistence manager interface and can then be configured in 
the repository.xml. people then can decide on their own if they wish to use 
it or not.

regards
  marcel

Mime
View raw message