Leonardo Rochael Almeida wrote:
What are these rules? what happens if an application doesn't follow
them? Do we get Conflicts just like before or are we suddenly bound to
make the application follow the rules?
The important rule, which only has to be followed by the portion of the
application runn
On Fri, 2003-05-30 at 11:06, Shane Hathaway wrote:
> I hear only crickets. I said we can avoid nearly all conflicts in
> sessions. Does this not interest anyone?
It does interest me, even though I'm not currently suffering from
Conflicts. But the discussion seemed a little over my head so I did
On Fri, 2003-05-30 at 11:01, Shane Hathaway wrote:
> The basic idea is that you track changes to session data in a replayable
> way. If a conflict error happens, you roll back the session data, bring
> it in sync with the current state of the database, and replay the
> changes, all during trans
Chris McDonough wrote:
It interests me! ;-) I haven't had time to look at the resources you
posted, though...
Oops, I didn't intend for you to analyze those links deeply. I just
wanted to see if there was interest in the idea.
The basic idea is that you track changes to session data in a repla
It interests me! ;-) I haven't had time to look at the resources you
posted, though...
Dieter also sent me a different transient object container
implementation before which has better conflict avoidance. I have not
been able to look at that either. :-(
Guh.
(We either need an internal projec
I hear only crickets. I said we can avoid nearly all conflicts in
sessions. Does this not interest anyone?
Shane Hathaway wrote:
A while ago I experimented with ways to prevent conflict errors from
reaching the application. ZODB has matured since then and it should now
be possible to make a
