Discussions

EJB design: Session Bean Persistence

  1. Session Bean Persistence (3 messages)

    Hi,

    It might sound strange what I am asking, but my specs require that:

    -My rich client should have a single point connection to the appsrv (ie. one statless session bean)
    -I need to have the possibility to execute some commands in an independent, multi-threaded manner (ie. my UI client needs to run a search in a window while browse some data in other window.
    - this needs to be able to run in a clustered env.

    For this multi-threaded access manner I thought to somehow use a session facade (that can be called by mltiple threads of the same app) and to delegate each command request to the
    respective framework (stateful session bean).

    The problem is: would it be possible to persist the state of a stateful session bean (involving also JDBC connections etc) without exporting the reference to the client? In fact to store somehow the reference inside the appsrv envirnoment to be later found by the facade bean?
    The EJB specs say that an ejb object lives as long as
    someone keeps its reference. As long as the stateles session
    "dies" after each call it's clear that I cannot have the reference stored there.

    The only working solution I see is to export all the stateful references to the client, but they asked me to avoid this as possible in order to get a high decoupling.

    Well, I'm a little confused.

    Some JNDI approach? Or perhaps I got the wrong architectural view?

    Any ideas would be appreciated.
    Dikran

    Threaded Messages (3)

  2. Session Bean Persistence[ Go to top ]

    use a lightwight entitybean, which doesnt persist anything or even things u need in the current session.
    an entitybean could be found using findBy... and then u can store your data.
    the entity bean is now something like httpsession, but in your j2ee container.
    problems: clustering, look to the containers vendor doc to figure out how clustering and data sync is made

    ...have fun!
  3. Session Bean Persistence[ Go to top ]

    Marco,

    Thanks, this could be a solution, I'll give it a closer look.

    I was thinking about a "breaking the law" alternative, where the facade would be a Stateful Session Bean for which (choosing the right server) I would allow for concurent acces to its methods. In this way, I would have all my other stateful references bound to this bean so my client could do it's concurent tasks. The persistence logic would remain handled in the stateless/entity way. However, having known that the SSB instance lives all his life in the same VM, I think this aproach would be intended for non-critical operations like paged searches and reports, that can be afforded to be lost in case of a server crash.

    cheers,
    dikran
  4. Session Bean Persistence[ Go to top ]

    ... be careful with concurrent calls, cause many containers do not allow this, also ejb spec. says that it is forbitten to call statefulbean methods concurrently. i know tha bea's weblogic allows conc. calls.
    there is also a solution, called HASessionState (high available an also clusterable), but this is only used in jboss3.x.x. You could co the CVS and build your on HASession for your container.

    tell me please, if you have a good solution.

    thx, cy