JDK-6323764 : Add support for client sessions to JMX API
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 5.0,6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2005-09-14
  • Updated: 2010-07-29
  • Resolved: 2008-06-18
Related Reports
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.

EVALUATION We are not current planning to address this in the JMX 2.0 API (so in Java SE 7).

EVALUATION See <http://forum.java.sun.com/thread.jspa?messageID=4354367> for another use case: retrieving the results of a database query.

EVALUATION Currently suggested for Dolphin (Java SE 7). The current idea is that the session service would be an MBean in the JMImplementation domain. To create a session you call a method on this MBean, which specifies what sort of session it is. Each session is also an MBean, and the exact MBean class corresponds to the type of session. Sessions are also registered in the JMImplementation domain. This means that you can tell what sessions are in progress with MBeanServer.queryNames, you can see a session's status with MBeanServer.getAttribute, you can be notified of changes in the status with MBeanServer.addNotificationListener, and you can renew the lease with MBeanServer.invoke. Possibly, you can terminate a session by unregistering its MBean, though there are questions about how a client can know whether a session terminated successfully if the MBean is no longer present. There may be security considerations related to the fact that every client can see all sessions unless its permissions have been carefully configured to prevent this.