** Replies are in ** :)
So, what you want is a cluster wide singleton. This application object
complicates matters somehow.
** Exactly that is what I want.
>
> 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.
** I was not aware. Thanks for information. Currently we are using
Weblogic and Jboss. But is should be compatible with all application
server. So it means this solution is not going to work for application
servers. Agree
> 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?
** Agree. Would like to know the overcoms for this.
> 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.
** Completely agree. One more thing that I would like to mention it is
that I said it is feasible which means that it loks for me that it is
the only solution. Definitly I need do some R&D before taking this
decision. Thanks for your comments which has done more then 80% of R&D
for me.
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
*** It is yet to be decided. The login module is not in place yet. But
as long as my knowledge goes, it would defintely going to look like this
only.
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?
** I agree with your solution. Let me explain the scenarion. The current
product is following an iterative development process. So there are some
modules which are ready already (though we have not considered the login
thought at that time) So we are looking for such a solution which will
not change any present code. So lloking for a solution which is
independent in it's own. That's why we are loking for as Application
wise object. I am agree with youir solution and we need to figure out
how can we do that. If we can't, we need follow as you said...no way out
:(
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.
** I agree Jaun. The first solution which came to my mind is this one,
which you have suggested right now. We are already using JavaGroups and
I have some knowledge about replication of session with JavaGroups. So
this was a given a though alreay. For me it looks like a lot of n/w
traffic since you need to reflect the changes in server and in real time
aplication how it is going to behave is not sure..As you know there are
certain drawbacks with this approch...performance. And hence I have
approched to this list, so that I could figure out is there any other
way that I am missing? Or I don't know?
** What do you think? Considering all approches,
drawback...performance..etc.
Looks lie making a bena level change is a lot of effort but gives
assurance, as you have already suggested.
** Thanks for Reply. Saidas
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".
MASTEK
"Making a valuable difference"
Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
In the US, we're called MAJESCO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that of Mastek
Limited, unless specifically indicated to that effect. Mastek Limited does not accept
any responsibility or liability for it. This e-mail and attachments (if any)
transmitted with it are confidential and/or privileged and solely for the use of the
intended person or entity to which it is addressed. Any review, re-transmission,
dissemination or other use of or taking of any action in reliance upon this
information by persons or entities other than the intended recipient is prohibited.
This e-mail and its attachments have been scanned for the presence of computer
viruses. It is the responsibility of the recipient to run the virus check on e-mails
and attachments before opening them. If you have received this e-mail in error, kindly
delete this e-mail from all computers.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
===========================================================================
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".
