|
| Re: Is there support for long transactions? [message #718733 is a reply to message #718508] |
Thu, 25 August 2011 08:09   |
|
I am not sure if I got it right so I try to answer in a general way:
Every scout client-server service is stateless like an ordinary webservice. So you cannot keep a state on the service itself.
A wizard typically contains serveral steps, each step assigned with a form. Each form has its own ProcessService and FormData to load and store the data of that form (not knowing anything about the wizard). To share a state between the wizard steps you need to keep that state in the wizard itself (with an instance variable). When starting the form in a wizardstep you can set that state on the form if necessary (with a form bean which also is on the form's formData if correctly annotated and therefore available in the form's process service).
If you need to store the state permanently you could either use a business process engine on the backend side or have a look at scout's WorkflowService which I personally don't know very well.
Best regards
Claudio
|
|
|
|
| Re: Is there support for long transactions? [message #718775 is a reply to message #718755] |
Thu, 25 August 2011 10:10 |
|
Hi Pietro
Actually I think your solution is pretty well for your usecase beside that the formData holder object doesn't necesserly have to be an ordinary formData which is autogenerated since it only holds your formDatas. When finishing the wizard (execFinish) you can call a service giving the formDataHolder as parameter. The service can now call the store of each process service with the appropriate formData.
Scout creates a transaction on the server for each client to server service so a rollback should be guaranteed if something goes wrong when storing one of those formdatas.
Btw: Neither the workflow service nor the bpm engine solve that problem automatically.
Btw2: Another solution would be to regularly save the data but setting it to inactive. When the wizards finishes or cancels you could either activate or delete it. But I like your solution more than that 
Regards
Claudio
|
|
|
| Re: Is there support for long transactions? [message #719146 is a reply to message #718775] |
Fri, 26 August 2011 07:51 |
 Pietro Bonanno
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
What about this approach:
- every FormData involved in a long transaction (LT) has a boolean flag LongTransaction
- when the form runs inside a LT, it's flag is put to true by a MasterProcessService and the form is used as usually
- the form's ProcessService reads the flag, if true then no CRUD take place and the FormData is saved into server session (together with infos about the operation to execute), else the normal CRUD is executed
- going on, the sequence of FormDatas is collected (sorted by insertion) in server session
- in the end, the MasterProcessService commits: the sequence of FormDatas is passed to corresponding ProcessService's operation with LongTransaction put to false (so every ProcessService execute the real CRUD)
The advantage of this approach are: I can reuse the existing FormDatas and its services, with a little overhead (manage the flag), I can manage complex workflows (i.e. first create something, then update something else, then delete, etc.), and I do DRY .
The disadvantage are: server session full of heavy data, some additional coding when a form needs data from previous steps (which would be written only at the end of LT).
My doubts are:
- Can I access the server session inside a ServiceProcess?
- ServiceProcesses are transaction aware? (i.e. if I call a SP inside another SP, is the transaction propagated?)
Hope I was clear...
I'll try this in the weekend, every suggestion would be really appreciated
Bye
|
|
|
| Re: Is there support for long transactions? [message #719266 is a reply to message #719146] |
Fri, 26 August 2011 14:40 |
|
Quote:- Can I access the server session inside a ServiceProcess?
-> Yes, ServerSession.get()
Quote:- ServiceProcesses are transaction aware? (i.e. if I call a SP inside another SP, is the transaction propagated?)
-> Yes, the transaction is committed when the remote service call returns to the client. (see ServiceTunnelServlet.RemteServiceJob. The commit is executed when the ServerJob#runTransactionWrapper() is finished ).
|
|
|
Powered by
FUDForum. Page generated in 0.03846 seconds
] 
Search
Help
Register
Login
Home
