Le 19 août 2009 à 04:15, Niclas Hedhman a écrit :
Well, if you want to serve potetially incorrect data, that's up to
you...
Nobody wants that.
Locks on entities -> sounds very expensive on every operation to
protect against seldom occuring events.
Seldom occuring *exceptions*. Nobody wants that either.
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....
Sure, my first architecture was very usual and based on three layers :
UI, Backend & Storage.
Qi4j was only used on the backend and storage part at first, and soap
(CXF) was used to communicate between UI and backend.
But I fell in love with Qi4j and wanted to use it everywhere so I
tried the RMI remoting of services interfaces, but for the first
version of the project everything will work on a single machine so I
tossed it (the RMI) but I know it is still there when I'll need it.
Right now I am using Qi4j directly in Wicket with a custom
UoWRequestCycle processor and I am loading model objects (using the th
threadlocal uow) with a DetachableModel in order to only save the
identity in the session (will probably switch to stateless pages later
to enable efficent load balancing).
As I had direct access to my Qi4j model objects I began to call
business methods on them directly, not through my previous RMIable
service interface (that I am planing to remove a now).
This is very efficient an practical, really! I tried to adapt the Qi4j
entities to the javabean spec in order to use WicketWebBeans but it
did'nt work as planned.
So the problem I face now is the boundaries of my uow, but as I said
previously I will simply discard all long living uow in the wicket
RequestCycle processor and I will use short living and repeatable
nested uow for business methods.
So thank you for all your help, I will try to find the time to write a
sample application using all that later (after 1.0 is out), if you
want to.
Philippe
-- 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
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
