(6) stateful and stateless

Serviceobject is usually stateless, that is, it is put into the pool after use. When another call activates it again, the execution behavior is the same each time, some information stored in the memory of the last call will not be used, because the order in which the component is activated and called is random. It may be activated by Client A and activated by client B again, it will be activated again by client a next time. If the status is retained, pay attention to how the status is used.

It does not mean that the component must not be in a state. You can retain the state of the component as needed. For example, we want to design a serial number generator in the memory. Each time the component calls getnewoid, a new serial number is obtained. These serial numbers are continuous, therefore, we have a variable of the current number inside the component. Each time we add 1:Toidserviceobject = Class (tserviceobject) <br/> private <br/> fcurrentoid: integer; <br/> published <br/> function getnewoid (const aparams: olevariant; aasynccallcontent: tasynccallcontent): olevariant; <br/> end; </P> <p> function toidserviceobject. getnewoid (const aparams: olevariant; aasynccallcontent: tasynccallcontent): olevariant; <br/> begin <br/> Inc (fcurrentoid); <br/> result: = fcurrentoid; <br/> end;

Of course, this component requires a single instance to achieve the expected effect. Otherwise, you need to move the fcurrentoid attribute out of the component.

A special stateful application is the client to control the transaction of the database.

1. When the client calls begintransation, The dbserviceobject component of the server uses its tadoconnection. starttransaction to start transaction and returns the ID of this dbserviceobject to the client: serviceobjectstub. At the same time, the server locks the dbserviceobject component and does not allocate it to other clients for calling.

2. When the client calls committransaction or rollbacktransaction again, serviceobjectstub needs to be passed to the server at the same time. The server finds the dbserviceobject and then uses tadoconnection to execute committransaction or rollbacktransaction. The server also removes the lock on this component.

Because it is the transaction controlled by the client, it may also be due to communication issues. After the client initiates begintransaction, it may be unable to communicate with the server due to network reasons or when it is on its own, the server needs to set a time to automatically unlock those dbserviceobjects that are locked for a long time. Based on this, it is generally recommended that the client do not control transaction, and should be handed over to serviceobject for internal control as much as possible.