[Mono-list] Any interest in a new open source project?

[Jon Watte]

> but if you change an attribute in object o1 is that change 
> visible in object o2? I think not and I would very much like 
> that to be the case. 

If you're running a multi-threaded application, and different 
threads do work as part of different transactions, then it's 
pretty clear that changes to o1 should NOT be visible in o2, 
unless the transaction that o1 was viewed as part of commits 
before you get o2. Transactional semantics require this.

If you want to always get a copy of o1 when you ask for the 
same object within the same transactional scope, then that 
should be almost trivially simple to layer on top of the 
existing API you describe, with a hash table placed in front 
of the object-getter function.

> When I played around with this kind of stuff myself a basically created 
> a hashtable per transaction and cached all loaded objects in this 
> hashtable by their primary key. This way there can only exist a single 
> instance for each primary key (per transaction. Different transactions 
> sees different objects.)

I think this is perfectly reasonable. An object wrapper that 
does not itself know about a specific transactional system is 
modular, and can easily be used transactionally, as you did. 
Tieing an object wrapper system to a specific database or 
transaction model seems un-wholesome, and requiring that your 
object wrapper be told about specific transaction commits is 
also not something that feels right.

Cheers,

			/ h+