[Vishnu-developers] googling

[<her...@gm...>]

marian,

estuve buscando otro rato sobre el problema de las sesiones en internet
encontre un post en news que discute el problema que tenemos con las
sessions en RMI.

lo pego a continuacion por si tenes curiosidad.

SK,  Read below!!!

Steven Owens wrote:

>      Yet another idea that never made it to the top of my "to-do" list
> was to hide the whole RMI-ness of it so the servers would seamlessly
> switch from using local calls to RMI calls, depending on whether they
> were running under the same JVM or not.  I couldn't think of an
> elegant way to handle it at first, but I arrived at the idea of having
> a singleton connection factory.  On startup each server would register
> with the registry and stuff a local reference to itself into the
> factory.  Then the factory would return either a local reference if it
> had one, or get an RMI reference.  I never did work out all the
> details.  Does this sound like a good idea?

I got that implemented.
I have a service interface called Reflector, which is a Reflection API to
reach java objects through the use of dot-notation String names, such as
App.MainContainer.PresentValues['23'].Profit.Value
Since that service is pretty handy, I have a RemoteReflector interface is t=
he
same but also throws RemoteExceptions. Both the RemoteReflectorImpl and
ReflectorImpl implements the Reflector interface, and the Connection
factory (connection is estabilshed by connection strings) returns the local
reference (if ound within the same JVM) or the remote reference, but the
client always cast to the Reflector interface.

> > Not so easy approach...
>
> > Create your own SocketFactory, Client and ServerSockets, which will
> > either upon Connect, or explictily requested and set by the client,
> > negotiate a session object or ID. And this session object is sent
> > along in each following request, not visible to the client code.
>
> > The server side could use the ThreadLocal system to place the
> > session object available to all parts of the code that are part of
> > the execution path without changing existing method signatures. (Why
> > have I not thought about that before?)
>
>      Or it's quite possible I'm not understanding what you wrote.
> Care to elaborate?

I am not sure what I meant. It was a spur of the moment, and got carried aw=
ay
with the ThreadLocal idea.
I presume it could be a possibility where you have cemented interfaces, tha=
t
can not change, but where Session information is needed in later upgrades. =
It
just struck me at that time, that ThreadLocal may be used to extend the
interface without breaking compatibility in those interfaces.

Sessions management part II.

The Client request a Session object, which in fact is a remote object, and =
all
session based requests go through this RMI object, instead of directly to t=
he
service object.
EASY!

I am also not very accustomed with Sessions as a concept. I prefer stateles=
s
requests, where anything may happen asynchronous and where connections may =
be
lost and reestablished without any implications of server complexity.

Niclas