axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kovács Péter <peter.kov...@siemens.com>
Subject EBJ Stateful Session Beans
Date Mon, 13 Jan 2003 15:46:07 GMT
Anyone working on an improved integration of EJB Stateful Session Beans? Is
it possible to integrate them at all based on the current JAXRPC
specification? There seems to be no appropriate component of the JAXRPC API
that could be used for the EJBObject.remove() method. Or may be setting the
session.maintain property to false on an already "used" Call instance may be
implemented so as to result in calling the remove() method on the cached
remote interface? In other words: are the properties of a Call instance
still writable after a connection has been established and associated with
the instance? (I assume that that the binding instances returned by
ServiceLocators internally use the Call interface. Actually, I do not know
where this ServiceLocator layer comes from. Is it an Axis specific concept?
I did not find it in the JAXRPC spec.)

I am also wondering what would be the best way to deal with the
NoSuchObjectException as a result of a session timeout. My instinctive
approach would be doing nothing and letting the user catch and deal with the
exception. The user would typically deal with the exception by re-creating
the service instance, which will result in obtaining a new EBJSession
reference. An alternative solution could be to override in EJBProvider the
invokeMethod method so that the session cached reference would be
invalidated and the exception would be re-thrown. (It is clear that the user
must be notified of the previously used session having become invalid, since
the user may implicitly rely on state information associated with the
session.) With the second approach a new remote interface to the stateful
session would be obtained and cached automatically. Technically this is
acceptable and even simpler to use than the first approach, but --this is my
vague feeling-- it is likely to lead to some confusion by not exposing the
semantics of session creation. I do not know, however, how the first
approach could be translated in the ServiceLocator et al. layer. My guess
would be that the user should regenerate the binding instance using the
appropriate ServiceLocator.

Any comments are appreciated. (Please, do not treat me very harshly, if I am
missing obvious elements in the axis implementation (or in the JAXRPC
concepts for that matter): I am much more of a casual user than a developer
of Axis. (That's why I am posting on the user list.))

Peter

Mime
View raw message