do you mean share state for a given session?
One web-module (W1) provides interface to client application and hence has knowledge of client sessions. Other web-module (W2) implements web-services and gets events/requests from a different source. W2 needs to modify session data which is inside W1. Also W2 posts JMS messages on a JMS topic which are picked by MDBs inside an EJB module. These MDBs also need access to session data maintained by W1.
i would use a DB to store the data, even if it's not long lasting. i don't think it's a good idea to modify session data explicity--i would recommend the first web-module (W1) query for the current data.
However I can not use DB. Idea is to ship these 3 modules to our customers, who will develop/package the final j2ee application. So the final j2ee application will have our modules as well as customer developed modules. This final application may or may not have DB and I don't want to make any assumptions.
Is there any non-DB solution?
Why not use a Stateful bean; if you an build a mechanism such that the two web modules may share the stub (obtained from JNDI), then you can centralize all application-session data in there. Just make sure that only one request (Thread) is accessing the SFSB stub at any one time.
I would think of the two web layers as clients to the Application, and the SFSB you make to represent a Session in that Application.
Thanks ALR. Couple of follow-up questions:
Q1. How do I make 2 web modules share the stub for the SFSB?
Q2. How do I access the same instance of SFSB (as used by web modules) from my MDBs?
On both accounts, the short answer is: that's entirely up to you.
If both web modules, the application, and the MDB are deployed in the same JVM, that should make things easier for you; you'd be able to make a central registration point (probably backed by a Map so you can do key-based lookups) to hold the SFSB stubs such that they could be obtained from either webapp (remember, only one can have access to any one stub at a time).
As for the MDB listener - I haven't seen the size of this SFSB, but if its small enough you could probably send it as a field of a POJO in an ObjectMessage. Or have the MDB do the lookup just as the webapps are through the centralization.
Again, I don't have your specs...the above are simply some ideas that jumped out at me without fully analyzing your particular problem.
And of course, be sure to call your @Remove method on the SFSB when you're done with it.