Michael Hunger wrote: > I don't think it is reasonable for an entitystore to access the store of an > entity state. As stated previously by > Rickard there is only one EntityStore per Module and so per EntityComposite. > What the RMI store tries to do is to > distribute/delegate the storage operation of the entities to the different > entity stores of the entity composites. (But > only for prepare, the other operations are performed with the default entity > store thats injected (in this case a > MemoryStore). > > Perhaps just using a new (server side) uow to persist the states that were > transferred via the wire would be enough? > > If the objects originated from this remote store and their state is > transferred back, its reasonable to argue that the > currently injected store is responsible for persisting them.
I should say that I have already done a refactoring of the RMI store as well which fixes these problems. Like Niclas said, it does try to emulate a regular client as much as possible, so doesn't use that much of the SPI/runtime. I'll try to clean it up and commit it, and maybe you can see if you've done some changes that would be useful as complement. In the future the RMI store needs to be rewritten anyway, in two ways: first of all the loading must consider "load policies", i.e. client-defined policies for eager-loading. Second, the storing should be done by sending commands of changes, rather then state. That will be much better I think, especially for collection updates. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
