On Dec 15, 2005, at 2:59 PM, Jesus Cea wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The mailing list seems fairly slow :-p
>
> David Binger wrote:
>> I think it would be safe to drop it, if you don't need to worry
>> too much
>> about packing out "lost" instances.
>
> In current Durus, packing is needed only to clean up:
>
> * Old instances, replaced with updated ones.
> * Garbage instances, unreachable from "root".
>
> The first is already solved with BerkeleyDB "per se". Now I'm thinking
> about the second one.
>
> The obvious path is using reference counting with objects.

That's not sufficient, since you can have lost cycles.

>
> When an object is loaded into the cache, we know what other persistent
> objects it references. My idea could be to keep that info, even
> when the
> object is modified.

Are you using the record format that includes the references at the end?
Is that how you know what it references?

>
> In the commit step, we simply compare the original reference info with
> the new one. With that comparison we can update reference counters in
> each object affected and release the garbage. So, the update can
> affect

This approach sounds complicated, but interesting.

> several objects, but since BerkeleyDB is ACID and updates are saved in
> write-ahead files, performance should be good and integrity is
> garanteed
> (if my code is bug free, that is :-)

Good luck with that feature.
>
> Is Durus threadsafe?. Looking at the code, I don't think so :-?

I think that Durus clients can be multi-threaded, as long as
there is no Connection that is used in any way in multiple threads.
This is, I think, the same rule that ZODB clients should follow, and
it is pretty easy to follow, since normal code would not provide
Persistent object references from one thread to another.

The storage server serializes operations by handling one at a time,
in a single loop in a single thread.

I don't think either qualifies as threadsafe, but both could be
used, with care, in multi-threaded processes.