|There's more than one way to do things|
An alternative approach using weak references (Re: Are array based objects fixed length?)by robin (Chaplain)
|on Jul 26, 2002 at 13:33 UTC||Need Help??|
From your description, I think your actual problem is to find a way of preventing the same (database) object from having more than one "live" realisation at a time.
I agree with those other posters who believe that your suggested approach is doomed, because it makes too many assumptions about the way that objects - especially array-based objects - might be used. I suggest taking a different tack, outlined below.
Keep a hash in the Pixie package, let's call it %objects, which uses the object ID number as a key and has a weak reference to the allocated object as its value. Whenever anybody calls get, the first thing you do is to iterate through your hash looking for undef values; if you find one, unlock the object in the database.
One disadvantage of this approach is that objects won't be released immediately they go out of scope. Instead it will happen the next time somebody calls get. I'm not sure how much of a problem that is for you. Another potential problem is that scanning the hash might become slow if large numbers of objects have been allocated. Obviously you can trade these two problems off against each other: at one extreme, if timely release is not required, you could not bother to release objects at all until exit time. The hash would then just be used to check that no instance of the object is already in existence. Somewhere in between the two extremes, you could do a "garbage collection" run whenever the number of allocated objects exceeds a certain number.
(In a multithreaded setting, one can also imagine a JVM-like approach where a background thread periodically checks for expired objects.)
I hope I haven't misunderstood the problem.