[Twisted-Python] Inheriting from both pb.Cacheable and pb.RemoteCache?
Hi! In the PB howto, it mentions that it's typical and fine to get bidirectional synchronization between objects by inheriting from both pb.Copyable and pb.RemoteCopy. Is the case the same when it comes to Cacheable? I want a client to log in and grab attributes of objects as needed from the server, and any changes made to the objects on either side ought to be replicated on the other end. This looks like the way to accomplish that, but I want to verify my suspicion before Twisted bends my brain again. :-) Thanks! Steve
Hi,
In the PB howto, it mentions that it's typical and fine to get bidirectional synchronization between objects by inheriting from both pb.Copyable and pb.RemoteCopy. Is the case the same when it comes to Cacheable?
I've wondered about it too, and after thinking about it I decided it was a bad idea. In the copy case (which works fine) you get a one-time copy through serialization when doing remote methods. In the Cacheable case though, objects get changed on the other side due to changes on the one side. So in practice, what does that mean when side A changes the same object as side B ? What do you do with conflicting changes ? It seems to me you have no predictable way of resolving clashing changes. So I ended up not wanting to deal with those situations and worked around my need for this. Now, I do think in practice it will probably work, just not reliably and very hard to debug when it doesn't do what you expected. Write a small test app and give it a try. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> The girl that I could never hurt had to go and lose all that power over me and I claimed victory <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
On Wednesday 19 January 2005 02:16 am, Thomas Vander Stichele wrote:
Hi,
In the PB howto, it mentions that it's typical and fine to get bidirectional synchronization between objects by inheriting from both pb.Copyable and pb.RemoteCopy. Is the case the same when it comes to Cacheable?
I've wondered about it too, and after thinking about it I decided it was a bad idea. In the copy case (which works fine) you get a one-time copy through serialization when doing remote methods. In the Cacheable case though, objects get changed on the other side due to changes on the one side.
So in practice, what does that mean when side A changes the same object as side B ? What do you do with conflicting changes ? It seems to me you have no predictable way of resolving clashing changes. So I ended up not wanting to deal with those situations and worked around my need for this.
Yeah, my intent is to protect simultaneous changes through a locking mechanism, which will prevent one client from altering a record while another client is working on it. (If that sounds like row-level locking to you, you're right.) Of course, network latencies may allow a conflict to occasionally occur, in which case the conflict should be detected by the server and it will do the arbitration to enforce integrity. But, of course, all this only works nicely if inheriting from Cacheable and RemoteCache is fine and dandy.
Now, I do think in practice it will probably work, just not reliably and very hard to debug when it doesn't do what you expected. Write a small test app and give it a try.
I was afraid you'd suggest that. :-) Thanks, Steve
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> The girl that I could never hurt had to go and lose all that power over me and I claimed victory <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
participants (2)
-
Steve Freitas -
Thomas Vander Stichele