2011/8/2 Falko Bräutigam <[email protected]>: > CopyOnWrite would be very cool but does not help in situations where writers > outside the JVM can access and modify the backend. I think CopyOnWrite would > help with efficiency not consistency.
Well, in general one should avoid behind-the-app modifications on data sources, as it really kills the ability to be consistent. You correctly observe that CopyOnWrite has nothing to do with consistency. >> 2. Disk-based cache extension, so that only N MB is in-memory and >> then overflows to disk. > > Most backends are fast enough to reload entities every time they are needed > - they have to do it when starting/loading an UoW anyway. Re-storing all > unmodified entities in some other disk based cache would introduce a lot of > disk/cpu overhead. Holding just the lastModified timestamps should be > enough. (?) Not lastModified ts, but the instance version. > If there would be an SPI the plugin any UoW cache implementation, then one > could decide which is the proper strategy for a given application. I my case > with lots of unmodified entities I would use soft-reference cache, where in > other situations with lots of modified entities a disk-overflow-cache would > be better. > Say displaying a list of spatial features as the result of an query (maybe a > bounding box) in a GIS app. The user selects the rectangle of the bbox, the > result gets displayed in a table. The user then sorts the table for one > column, picks an entity, opens an editor... > Unfortunatelly sorting in the backend is not an option because most > properties are computed. So IFAIS I need to fetch all entities to sort them. > Just a few entities are used afterwards to display the visible lines of the > table. Almost all entities are probably never used again. The cool thing > with the soft references is that, *if* the user makes some more selection > and/or sorting, then all this is very fast as long as there is enough memory > to hold all the entities. So if you are a client-server application (with a model in a middle tier), then I wouldn't have designed it this way. This seems like a typical case of CQRS, where you would return values to the client, not interacting with a user session in the model on the server, then client construct a command back into the domain model, which emits domain events to update the client view model. That said; I think that a UoW cache extension mechanism is a valid point. So please create a Jira issue about it on http://team.ops4j.org/browse/QI Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
