Duplicate :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
It is often the case that a remote JMX client wants to perform a number of operations, with some state required across these operations. Currently this requires coding ad-hoc solutions. It would be much better if there were standardized support for client sessions. At a minimum, a session would retain the notion of who created it and when it expires. Expiration would be handled with a leasing mechanism, so a client could extend the lifetime of a session by renewing the lease. Mechanisms should be provided to automate this. If a client fails or loses connectivity before the session completes then the session will eventually expire and its state can be cleaned up. Examples of when sessions would be useful: * A thresholding or performance-measurement job that samples the values of certain attributes over a long period and sends notifications or stores summaries of the samples. The leasing mechanism ensures that orphan jobs do not live forever. * An asynchronous operation such as an audit or backup that might run for minutes or even hours. The session service would make it possible to get the status of the operation and see what operations are in progress. * A notification service which receives notifications on behalf of different clients and performs filtering and correlation before forwarding them. If a client's lease expires, it can be removed from the notification service. * Transactions (see RFE 5106222). The lifetime of a transaction is that of its session. If the session expires or is explicitly terminated, the transaction is aborted.
|