I have a design question:

I have a statefull Session bean, let call it EJB_A, who is the only interface to the clients, it follows the façade pattern. The problem here is that I have other statefull session bean, let call it EJB_B, who needs to store in memory information sent in clients requests. The fisrt idea is that the EJB_A establish a stetefull session with EJB_B and when the clients requests arrive in EJB_A to EJB_B, the EJB_A forward requests to EJB_B. What the main problem can you see here, and possible solutions.

Thanks

I wouldn't have too mane statefull sessions, unless I ABSOLUTE must. Can't you just store all the state in the statefull session that acts as a facade?
I you told me what functionality would your statefull session B implement, I could help some more...

Cheers,
Martin

Thanks for you answer.
The problem in my design is that I have the EJB A receiving client requests, only EJB A handles client request, and this EJB A needs to store information about the client between client requests, thus the EJB A have to be statefull.
The EJB B holds information sent by clients. The EJB B comports almost as an entity EJB, but instead of using persistent storing, it stores the information in memory between client requests. You can imagine EJB B having a Vector and in each client request a new object is inserted/removed or modified in that vector, so the vector must remain the same between client requests.

I hope you could understand my problem in that words.

Thanks in advance,
João Pereira

I see... Sorry about this, but this question is a must: what per-client data does EJB B store? And speed things up: why did you choose this approach instead of [insert the alternatives you evaluated here, if any]?

Regards,
Martin

Hi Martin,

The EJB B will store Objects called "commands" which contains low-level intructions to send into a mechanical machine. These low-level instructions will be sent by the operator, he can send as many as he wants, afterwards, the operator tell the system(my system) to generate a XML file having the commands he sent to the the system. In this case the Commands are stored in a list managed by the EJB B as the operator sends them, until the operator request to generata a XML file with them. Of course the logic of setting a command in the list is a kind complex, because the command has to be verified and post processed, this is done by the EJB B.
Later in time, when the operator already request to generate the XML File, this XML file can be consumed by other legacy system, who in turn send the commands to the machine.

The EJB A constains state information, that is the operator must performe some actions before perform others, example, the operator cannot do step B without successfully finish the step A, thats the information the EJB A contains.

Thanks,
João Pereira

I don't know, man. We should discuss a little more about some context. How many users will use the system? How heavy ar these "commands" in memory? How many of them does the operator send before commiting to the device? And so on.
Did you consider caching the commands on the client-side and send them all together? Something tells me this doesn't work for you, but I'd like to know why...

Regards,
Martin

Hi Pereira,

Is your client a http client (web based ? ) or a fat client w/o web tier ?



In any case, have your facade with a Plain Java Object. This facade acts as a facade + delegate. When there is a request to your server let this facade decide whether to invoke a SFSB_A or SFSB_B. Incase if you want to have a kind of business logic which mandates to call SFSB_A first before SFSB_B, let the logic be in facade and once you got the result to facade, if can invoke SFSB_B.

In any case, having a SFSB calling another SFSB may not be a good idea. As Martin mentioned, if you can make bothe as one SFSB, that will also solve you problem.

Btw, where are you storing you SFSB handle ?

Hello all,

The client is swing client w/o web tier.

The size of each command is around 2k, but can exists milions of commands. There will exists support for only one suppport in this release.

I'm thinking to store the handle of the EJB B as a instance variable of EBJ A? there's any problem with this startegy. whenever a request arrives to EJB A and the request is for EJB B, then EJB A logic will call the loginc in EJB B using the handle.

What the major problems with this?

Thaks all,
JP

I think that if there's a problems, it is with the statefull sessions. Millions of commands means 2 Mb (considering each command is around 2kb) IN MEMORY, UNTIL THE SESSION IS PASSIVATED OR REMOVED, for each user.
I'm sure you just MUST do it this way, for some low level detail about those misterious devices of yours.
What you should care when using statefull sessions, even more when there are calls between them, is that they are long lived, and if you are reckless about them you could end up with lots of them being created, passivated and ultimately removed without a good reason.