Well, if you want to serve potetially incorrect data, that's up to you... Locks on entities -> sounds very expensive on every operation to protect against seldom occuring events.
As for refresh() disappearing; the real problem was around refrshing a single entity, and a refresh of a whole UoW is effectively the same as re-building it from scratch. My app has very long-running UoWs (days) but don't need refresh, Rickard's has very short UoWs and is Ok with re-running the command on CCME. Also, something that is missing can be added if the use-case is well enough understood, but we can't remove something ill-defined without breaking compatibility. I don't have a clear picture on how you intend to build your app, but perhaps the comment from you that you tossed app structure out the window is a sign that you are heading down a troubled path... Is the work done so far something you could share? Or could you draw an architectural sketch.... -- Niclas On Aug 19, 2009 1:17 AM, "philippe van dyck" <[email protected]> wrote: The thing is, you can't always retry... if a web page was already sent (even a part of it) and uow.complete() is called after... it is too late. For this specific use case "web page producing", I don't care, I don't want to. And especially I don't want any other thread to be influenced by this use case uow. So Rickard is right, I should simply discard it. A simple NestedUnitOfWorkConcern on specific method calls will do the trick. When concurrency problems arise, another solution is to use locks... and open the door to deadlocks. But we don't have to lock complete rows or 'data pages' like a database, we could lock specific entity references and detect deadlocks. Actually, if you can atomically lock multiple entities at the same time like uow.lock(e1,e2,e3,..) and you can only do it once/uow, you won't have any deadlock. It sounds like defining the boundaries of your uow... Maybe, It is an alternative to uow version managment and the end of CCM ? I had a dream of long lasting transactions, with a possibility of "refreshing" the uow... locking will definitely ruin that 'long lasting' dream, but anyway, my refresh() is gone.... philippe Le 18 août 2009 à 16:35, Niclas Hedhman a écrit : > > Guys, > > I don't think GET -> discard() is semantically correct. > > Thread1 reads data1, threa... _______________________________________________ qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
