So, what you want is a cluster wide singleton. This application object
complicates matters somehow.
>
> 3. Use JNDI object (This solution looks feasible for me :)
> Thanks to Ashu for the same.)
> 1. Create your own object with the data that you want
> to share across the users.
> 2. Register this object in the JNDI tree of the
> application server.
I assume you're using Weblogic, where this would work. Registering an
object in the JNDI tree may not work across the cluster in every app
server(the JNDI implementation may not be clustered); check out your App
Server's documentation.
> 3. By registering the object, your data will be
> available across the cluster.
How precisely will this work with your app server? Won't it serialize
the object and send it thru the wire to each app server that requests
it? If you have a large amount of logged in users, won't it add
excessive network overhead?
> 4. Lookup for the object whenever you application
> needs the data.
> 5. Just think of the object as one whose reference is
> shared across the application server. You will need to make
> it thread-safe.
You need not just to make it thread-safe, you need to make it thread
safe across a cluster. No 2 threads on any machine on the cluster can
access it concurrently. You're *potentially* creating a bottleneck.
I suggest you PoC this carefully before commiting to this approach.
Now, here's my question: doesn't your proxy code look like this:
Hashtable hs = new Hashtable();
hs.put("host", "somehost.someuser.com");
hs.put("username", "someuser");
hs.put("password", "somepassword");
InitialContext ic = new InitialContext(hs);
//lookup goes here
Or something along these lines? Your EJBs implement a method
setSessionContext(SessionContext ctx); or setEntityContext(EntityContext
ctx); and from this Context, you can use getCallerPrincipal().getName()
to get the "someuser" that was passed in to create the InitialContext.
Most App Servers won't allow you to connect to them unless proper
credentials have been passed in, so ALL users will be logged in(the
exception usually is when classes from within the same JVM create the
InitialContext). Incidentally, you can also manage which users get to
execute which EJB method with this and some descriptor tweaking. So
then, why would you need the Application object?
Finally, if you decide to go for the Application solution and are having
problems synchronizing the access to it, or the network consumption is
prohibitive, you probably want to:
A) Use regular classes (or just a HashMap) to track session state.
B) Use a singleton object per machine to hold session state.
Synchronization will be handled separatedly.
C) Proactively REPLICATE session state thru the cluster (manually,
you'll have to code it).
For (C), take a look at:
http://www.javagroups.com
Which essentially is a library that takes care of broadcasting data
(i.e. a message "user X logged in") to a group of listeners (each of the
singletons, one per machine on the cluster). This is basically how App
Servers like Orion replicate session state thru a cluster with limited
Network and CPU consumption, relying on Multicast UDP to broadcast the
messages.
Finally: any road you take is going to be extremely difficult. See if
the InitialContext user credentials are enough for you, I'd certainly
think so, because other options will be really taxing in terms of
development effort and QA.
My 2c,
JP
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
