jakarta-slide-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Warwick Burrows" <warwick.burr...@e2open.com>
Subject RE: transactions in slide
Date Mon, 28 Nov 2005 16:36:12 GMT

As Ray has noted Slide keeps track of transactions by creating a lock for them. 

Separately to this the transaction management implementation (which does the real work of
keeping track of updates during a transaction and then committing them) must also keep some
transaction related information around to manage the transaction lifecycle. From what I have
seen of Slide's behaviour the transaction related information for the transactional file stores
is stored in the "work" directory defined for the file store. When Slide crashes and is restarted
the transaction manager uses the contents of the work directory to rollback the updates for
transactions that weren't successfully completed. Of course this is only for transactional
file stores as RDBMS stores store this transaction related information in the DB in transaction
logs.

For more information I would try the Jakarta Commons Transaction project as it's the commons
transaction implementation that underlies the transactional file stores. I believe Oliver
Zeigermann integrated the commons transaction layer into Slide and though he is no longer
an active committer on Slide he is still active on the commons transaction project.

Warwick


> -----Original Message-----
> From: Ray Sprinkle [mailto:rsprinkle@vhainc.com] 
> Sent: Monday, November 28, 2005 8:05 AM
> To: Slide Developers Mailing List
> Subject: RE: transactions in slide
> 
> 
> I should have been clearer.  All of my experience with Slide 
> has used one of the RDBMS stores.  In that implementation, 
> transactions seem to go in the lock table with the other locks. 
> 
> -----Original Message-----
> From: Guillaume Bailleul [mailto:eulguignol@gmail.com] 
> Sent: Wednesday, November 23, 2005 8:40 AM
> To: Slide Developers Mailing List
> Subject: Re: transactions in slide
> 
> That is one of my questions :-)
> 
> a LOCK method modify the node file associated with the 
> collection or file : a lock appear in the ".def.xml". It 
> seems to be different with transaction.
> 
> Are transaction only stored in work ?
> 
> 2005/11/22, Ray Sprinkle <rsprinkle@vhainc.com>:
> > A little more info for the pool:  Slide transactions are 
> tracked as a 
> > special type of lock in the lock table (or file).
> >
> > -----Original Message-----
> > From: Guillaume Bailleul [mailto:eulguignol@gmail.com]
> > Sent: Tuesday, November 22, 2005 10:11 AM
> > To: Slide Developers Mailing List
> > Subject: Re: transactions in slide
> >
> > Thank you for your help,
> >
> > My question is more about what is doing slide in the 
> callback called 
> > by JTA. How is the work directory used... Hope some slide 
> developers 
> > has some data about this. Reading source code without guidelines is 
> > not so easy :-)
> >
> >
> >
> > 2005/11/22, "Honoré David N." <dho@oma.be>:
> > >  Hi,
> > >
> > >  Slide transactions are based on JTA (which stand for java 
> > > transaction api). Each slide store is an XAResource.
> > >
> > >  When you do a begin/commit/rollback (in the NamespaceToken) Slide
> > > transmit to JTA, and JTA call slide 's store back.
> > >
> > >  I think it use one-phase commit (but not sure).
> > >
> > >  You can add (enlist) any other XAResource instance to the
> > > transaction and then the methods commit/rollback will be called.
> > >
> > >  I hope this will help you a little.
> > >
> > >  Guillaume Bailleul wrote:
> > >  Hi all,
> > >
> > > I'm looking for documentation on how work transactions in slide.
> > >
> > > I'm trying to make a working failover system on something 
> like this:
> > > a slide server stores files on nfs partitions. If the 
> slide server 
> > > breaks, a second server do the job. I'm looking how to make it 
> > > possible, what to do with started transactions, how to 
> come back to 
> > > the primary machine.
> > >
> > > To do this, I need to understand how transactions works internally
> > > with slide. So if you have some documentation, or some time ...
> > >
> > > Thanks for your help,
> > > Best Regards
> > >
> > > Guillaume
> > >
> > > 
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > slide-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > >  --
> > >  ________________________________
> > > Honoré David N.
> > >  Projet DISSCO (http://www.meteo.be/DISSCO/)
> > >
> > >  email: dho@oma.be
> > >  tel: 02 37 30 530
> > >  ________________________________
> > >
> > > 
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail:
> > > slide-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > slide-dev-help@jakarta.apache.org
> > >
> > >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


Mime
View raw message