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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]>: > > 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:[EMAIL PROTECTED] > > 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." <[EMAIL PROTECTED]>: > > > 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > -- > > > ________________________________ > > > Honoré David N. > > > Projet DISSCO (http://www.meteo.be/DISSCO/) > > > > > > email: [EMAIL PROTECTED] > > > tel: 02 37 30 530 > > > ________________________________ > > > > > > > -------------------------------------------------------------------- > > > - > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
