Services and Transaction Control

Author: (Colin)


Currently I have an end of day process that reads all the sales transactions generated throughout the day and uses them to update certain files. This process consists of one Uniface form that in turn "runs" other uniface forms to do all the required updates. These forms do whatever they need and then stores the changes without committing. Provided all the update forms finish successfully, the main form then issues a commit and all the changes are made permanent. If any of the update forms fails then the main form can issue a rollback and everything returns to its original values.

All works very well.

All of these update forms are perfect candidates to be activated as services. The problem I have is that each one has to store without committing. The testing I have done shows that when the service finishes and control returns to the main form, the changes the service made are lost (because there was no commit). I can't let the service commit the data because if any of them fail I need the whole thing to be rolled back, not just part of it.

Is there a way I can use services to do this or will I have to stay with the current processing.

I am using uniface 9.4.01

Colin Douglass


  1. Dear Colin,

    I assume you talk about an three-tier-architecture with using userver for your services, is that right?

    Than the problem is, that there can be several variants to design and build this.

    a) exclusive server processes, which are bind to your form (either by /ex setting in the uniface router) or by dealing with keep open instances.

    b) scalable server processes, which means that every call of an service can invoke on different processes.

    So what I suggest is, to build an controll service, which will called from your form (maybe a duplicate of your form, but without edit). In this service you can call all other services, but than you have to ensure that your userver doesnot redirect service calls to other userver. So you will have all services in one process.

    In a "classic" fat client application this problem shouldn't not occure.


    Best regards


    Author: Thomas.Young (
  2. If you call a service from a service, they are automatically run in the same userver and in the same database transaction, so the control service mimicking the current behavior of the form is the solution to this issue.

    Exclusive servers, would not solve it as they are run on a different database connection from the client, and the rollack would still happen.



    Author: Iain Sharp (
  3. Hi Colin, for me, the situation depends what your service is made of: a simple service acts just like a form but you can implement it for using "separate transaction" if you have a "self contained" service and run it on a remote machine: no way to share the same transaction. So one option is to have one service which controls all the other ones and commits at last. As Iain had stated, these services will share the same userver process (as long as noone ASNs it differently). Success, Uli

    Author: ulrich-merkel (