I don't think you should even attempt to version/transaction protect
a tied variable. Anything that leaves the memory or could leave the
memory (e.g. socket write) should probably not be versioned.
Unless the tied variable somehow is able to tie itself into the
transaction manager. It is up for grabs.
But if it participates then as far as the 'caller' or user is concerned
it looks like a variable and acts like a variable. It must be a variable.
<chaim>
>>>>> "d" == dLux <[EMAIL PROTECTED]> writes:
d> /--- On Thu, Aug 17, 2000 at 06:17:51PM -0400, Chaim Frenkel wrote:
d> | Though this is a tough problem especially in the face of threads.
d> | Though versioned variables may be able to remove most of the
d> | locking
d> | issues and move it down into the commit phase.
d> Yes, but you can give strange results when using a versioned tied
d> variable.
d> That's why I thought versioning and more intelligent locking has
d> quite a lot overhead.
d> \---
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
