We plan to use JMS and MDB’s to create a certain service. We need to maintain state between methods, which means between the JMS messages.
To demonstrate using an example , Lets say the service has 2 methods login and book..
I get a JMS message for a login, the service consumes it, and returns a token. Now, I send a JMS message for book, in which I pass the token. I would like book to access the state of login.
I guess the short of it is, I am trying to figure out a way to create statefulness using JMS and MDB’s.
If the main interest is to return a token to client after login, then probably temporary queue can help?
In short, the idea is that client creates a TemporaryQueue that is associated with Connection object (exist only for this connection lifetime), and pass queue name in its "request" message.
MDB can send a "response" with login token (or whatever else), using this queue name. Client consumes the response.
What about a session data you mentioned, is it something huge or more like several attributes?
What about the following:
After certain client logged in, and recieved back a token from MDB, this token can later be passed to MDB as clientID with all the following messages that belong to the same "conversation".
Or it's possible to pass clientID + some other attribute.
So, session state would be identified by clientID.
Pallav, do you mean application context used by Spring?
I think in (1) you are talking about sending all the information in the request itself.
(2) - saving in a session on the server, is what Iam trying to figure out.
If you have a servlet, I can see how one can have a session to save data in.
But if there is just a MDB how do you do it. Obviously, the session data should be available across servers.
I was talking about sending data in a message that client sends to a MDB, e.g. adding an attribute to message "clientState" or some other attributes. For this case client will send its state every time with a message.
By (2) - saving data on server (and no database), do you mean saving data in MBD for that it could recognize subsequent client calls and individual client data?
I have only one straightforward thought, to have a local hashmap inside an MDB with clientID as a key and session data as a value. But anyway, clientID should be passed in every message... and this all is only for little-sized session data
Storing in a hashmap, would make it accessible only if the next request goes to the same instance, the hashmap store was done in.
If I have 10 instances of a APP server ( lets say distributed among 5 physical servers ) - it would not work.