[Zope-dev] Distributed ZODB-Transactions

[Heine Gregor]

> > I want to write an Product that mirrors every ZODB-Transaction to a
> > Backup-Server.
> > The idea was to trap every transaction (i.e. creation, change, deletion
> of
> > zope-objects) and transfer a copy of the object to another server (via
> > XML-RPC?!?) after the transaction got commited.
> > I've been debugging through various zope-classes (esp. transaction.py,
> > connection.py) but couldn't understand the way, zope manages the
> > transactions.
> > The creation and deletion process always seems to trigger a transaction
> for
> > the parent object.
> > Has anybody an idea?
> 
> Data.fs is essentially a log file that is appended with binary data. 
> The only time the data is changed rather than appended is when you pack
> the database.  Therefore, it may be easier to write a script that
> catches the data that is appended and appends it to the backup file. 
> When the script detects the file has shortened (after a packing
> operation), it should copy the whole file over.
> 
> The simple fact that data is appended rather than changed makes Data.fs
> quite reliable.  It can withstand most kinds of failure.  And the Zope
> undo mechanism is very effective.
> 
> So I would suggest that the backup you intend to perform does not need
> to be an integral part of Zope.  Rather, it is appropriate that it be a
> background process run periodically.
> 
> Shane
	  
	OK, I admit, I didn't tell you the whole truth. ;-) 
	The Backup-Server should not only backup one, but various
Zope-installations (sort of 'backup-central').
	My idea was to create a folder for each backuped server. This folder
holds the complete object-tree of a backup-client. 
	Each time a change in the database of the client occurs, the client
informs the server about it (tells the server which object has been changed,
created or deleted). Then the server requests that object from the client.
The client pickles the object, sends it to the server and the server
unpickles it again and puts it in the right place in the client folder.
	My problem is the first step: how does the client recognize, which
object has to be updated? In the case of a creation and deletion of an
object, the transaction-class handles the parent object and not the object
itself.

	Thanx,

	Gregor!