On Tue, Oct 20, 2009 at 7:10 AM, Kent Sølvsten <[email protected]> wrote:
> The opens the possibility of later creating an ultrawicked cool loading > policy deciding the partitioning at runtime based on usage patterns. Or just > using a block per mixin. Or... We did something similar in 2001, but instead of storage it was about "network traffic". In that case, we had a "smart proxy" representing the "entity" on the client side. In reality, it was hollow and with the help of a "use-case" the server side would "learn" what to be sent back in the initial retrieval and upon each other request. In principle, the algorithm was fairly simple. All properties that were always accessed for the usecase would come in the initial request, all properties that were accessed more than half of the time (24 hour average) and all small payload properties would be transferred when the first access to such "block" occurred and the rest was only transferred upon actual usage. Since the logic was sitting on the server-side, i.e. "client request property A, but 8 properties are returned" was handled by the client side proxy hidden from client code, there were no "learning period" for each customer, EXCEPT for certain interactive UI operations, where the usage was large a product on the persons interaction, and hence was given its own "use case" ID. Another "side effect" of the remote protocol capable of returning "anything" on each request, was that cache updates was sent along as well, if another user had updated the Entity. (Our system didn't support user transactions, was purely atomic rest operations and even the the DB made no UPDATEs, only INSERTs when entities changed.) We chose this 'self learning' system with the algorithms on the server side, since we quickly realized that hand optimizations were near impossible to maintain in the long run. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
