On 13 June 2012 18:13, Chris Cunningham cunningham.cb@gmail.com wrote:
On Tue, Jun 12, 2012 at 8:13 PM, Igor Stasenko siguctua@gmail.com wrote: [snip]
This could be somewhat memory-hungry (but do we care?), but you don't
[snip]
As long as the Windows VM is severely limited in how much memory it can handle, some of us care a lot. It just depends on how memory-hungry it is, and how much memory we're already using.
no, it just about keeping a copy of working set of your transaction. And nothing will save you from memory problems if you start to abuse DB to load huge blobs of data, required for your working set..
and as i said, you have to use the copy anyways in case if you need to rollback transaction.
and nobody said that you cannot employ a hybrid approach: you can keep a copies of objects up to certain size/or for certain kind of classes and for the large ones you can still use the same write barrier approach. so you will have a best of both worlds :)
In terms of implementation, this is quite easy to do: since graph comes from database in serialized form, creating an initial copy is just about materializing same object twice (or materializing and then copying) instead of once. One will be used in working set, and another will be used to detect the changes upon committing transaction.