Eclipse Community Forums: Eclipse Scout » Is there support for long transactions?

Home » Eclipse Projects » Eclipse Scout » Is there support for long transactions?

Is there support for long transactions? [message #718508]

Wed, 24 August 2011 10:44

Eclipse User

If I don't get wrong, there is no support for transactions longer than a single call to a service. I'm actually defining a wizard which reuses detail forms, and every form has it's FormData. The easiest solution I see is to define a global FormData for the wizard and copy value from single FormDatas while wizard flows.
Is there some other pattern better suited for Scout?

Thanks

Re: Is there support for long transactions? [message #718733 is a reply to message #718508]

Thu, 25 August 2011 04:09

Eclipse User

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 #718755 is a reply to message #718733]

Thu, 25 August 2011 05:13

Eclipse User

I think you gave me the right answer, but I'll try to resume better my initial post: if I have a wizard composed of three forms, everyone with it's FormData and ProcessService, and the ProcessService is stateless. So it's not possible to do something like:

wizard starts (begin transaction) -> step1 (update data) -> step2 (update data) -> step3 (update data) -> End of wizard (commit if all went well, else rollback)

So my initial thought was to maintain all data in a bigger FormData into Wizard, which collects all data from every form. This seemed to me a 'shoot on my foots' solution Smile

I'll give a look to the WorkflowService you suggested (BPM is over the scopes of my simple application), but hope that this argument is interesting enough to hear for other solutions from the community

Thanks

Bye

Re: Is there support for long transactions? [message #718775 is a reply to message #718755]

Thu, 25 August 2011 06:10

Eclipse User

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 Smile

Regards
Claudio

Re: Is there support for long transactions? [message #719146 is a reply to message #718775]

Fri, 26 August 2011 03:51

Eclipse User

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 Smile

.

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 Smile

Bye

Re: Is there support for long transactions? [message #719266 is a reply to message #719146]

Fri, 26 August 2011 10:40

Eclipse User

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 ).

Previous Topic:	AbstractTable: Dynamic Columns
Next Topic:	Debuggable code?

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 11:46:42 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter