Life cycle of service and transaction

Asked by Igor

Between request and response, what are lifecycles of Service and Xaction?
Is there a way persist information between request and response if the service handles both?

Is there a diagram or some description of when objects are created, disposed?
And totally awesome would be to find a step-by-step sequence of method calls (note...() calls, make...() etc.)

Question information

Language:
English Edit question
Status:
Solved
For:
eCAP Edit question
Assignee:
No assignee Edit question
Solved by:
Alex Rousskov
Solved:
Last query:
Last reply:
Revision history for this message
Best Alex Rousskov (rousskov) said :
#1

The host application controls adapter::Service lifetime. In general, Service is created when the adaptation module is loaded, starts functioning when Service::start() is called, stops functioning when Service::retire() is called, and is destroyed sometime after that call.

The host application controls transaction lifetime. In general, adapter::Xaction is created at the start of REQMOD or RESPMOD processing by the host application and is destroyed at the end of that processing.

There is no predefined relationship between REQMOD and RESPMOD transactions. However, a developer can create persistent state that matching REQMOD and RESPMOD transactions can share. How you do that is up to you.

For example, you could assign a unique ID to each HTTP request and query that ID when processing the HTTP response. The ID can be given to the host application as transaction meta-information, provided the host application can share meta-information among adaptation transactions (e.g., see adaptation_masterx_shared_names configuration option in Squid). Alternatively, the ID can be added to the HTTP request headers and, optionally, filtered out before the request leaves the host application.

Please keep in mind that for every HTTP transactions there can be N REQMOD and M RESPMOD transactions, where N >=0 and M >= 0. Some or all of those N+M transactions may be concurrent. Your service may place additional requirements on N and M, of course, and the host configuration/operation would have to match those requirements.

As for the methods calling sequence, many adapter transaction methods are not called in a sequence, but when needed by the host transaction. That is the best model to keep in mind when developing them, IMO. There are many correct call sequences. For example, your code cannot fully control when the host application will want to get the next piece of the adapted body, but you know it cannot happen sooner than you tell the host transaction that there is an adapted body (and it may not happen at all).

It would be nice to document this better, of course. Quality documentation patches and sponsorships proposals are very welcome.

Revision history for this message
Igor (i-um) said :
#2

Thanks Alex Rousskov, that solved my question.