jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Pfister <dominique.pfis...@day.com>
Subject Re: Performance issues of using "object" repository rather than "orm"
Date Wed, 18 May 2005 13:42:00 GMT
Philippe Girolami wrote:
 > Dominique, any thoughts on this ?
Oops, replied too quickly on your previous post :-)

> If JR crashes, there may be a consistency issue which you brought up in your
> previous email. I suppose it is very difficult to make the store consistent
> again, is it even probable that the store would be unreadable ? I suppose
> not since it seems that each Item is stored in its own file. What is the
> extent of damage if a node cannot be read ? How many nodes does it affect :
> itself, parent & children ?

If JR crashes outside of a call to the persistence manager, unsaved 
changes may be lost, but the persistence manager's state is consistent.

As stated in my previous post, a persistence manager must either store 
ALL or NOTHING when its #store method is invoked. If it crashes there 
without clean-up, chances are good that data is corrupted.

> What if an XA transaction includes both JR and another application : what
> happens if the TM decides to rollback because of the *other* application :
> JR will not commit and thus everything will be ok ?


> So essentially, JR supports transactions unless it crashes in which case the
> consistency of the content stored is not guaranteed (although it is with a
> db-backed PM). Is this statement correct ?

As I said above: if JR crashes outside of a PM's #store method, unsaved 
changes may be lost but content stays consistent. If the PM crashes 
inside the #store method and is unable to rollback changes it made upto 
this moment, content stored may be inconsistent.


View raw message