Design Help - persistent session beans?

Apologies in advance for the newbie question ...

Our project is looking into integrating EJBs into our architecture, and had
an initial design question that I was hoping someone could comment upon ...

Our application runs on paired machine, and at any given point in time the
application is active on one machine.  There are multiple scenarios that are
transactions, and one of the main goals of switching to an EJB architecture
is for the transaction models.

What's the best way to keep the transaction states across the machines?
Everything I read discourages using persistent session beans, but that's
basically what we need.  I cannot seem to find a good design pattern to
address this problem either (client tokens is not feasible as we have 3
different types of clients, and storing any state on the client would be
expensive and difficult to maintain).

Any help, advice or pointers would be appreciated!

Joe V. wrote:
> What's the best way to keep the transaction states across the machines?=

> Everything I read discourages using persistent session beans, but that'=
s
> basically what we need.

Are you using remote EJBs? If so, you could obtain the handle of each=20
Bean and put it in the HTTP session. On the next request, take it from=20
the session, call getEJBObject() and there's the original Bean again.

Johann
--=20
b=FCrschen, pass bloss auf - ich bin eben gerade erst so einem haufen=20
entronnen worden..........usenet/forum - das ist mir alles einerlei!
("weihnachtsmann" in <1035825834.556325@jupiter.schunter.etc.tu-bs.de> )

Thanks Johann.

The problem is that only one of our interfaces is Web-based and uses
Apache/Tomcat ... the 2nd interface is command line (currently uses RMI
straight to the parent object) and the 3rd is a CORBA-based interface for
which our group only provides the API i.e., we do not have development
control.

BTW, currently we're in the design phase and we use no EJBs in our
infrastructure ... one thing I fear is that we will make a design decision
today that will bite us in the future. So, any advice would really be
appreciated.

Thanks!

joe varghese

"Johann Burkard" <johannburkard@nexgo.de> wrote in message
news:40546a33$0$7996$9b4e6d93@newsread2.arcor-online.net...
Joe V. wrote:
> What's the best way to keep the transaction states across the machines?
> Everything I read discourages using persistent session beans, but that's
> basically what we need.

Are you using remote EJBs? If so, you could obtain the handle of each
Bean and put it in the HTTP session. On the next request, take it from
the session, call getEJBObject() and there's the original Bean again.

Johann
--
bürschen, pass bloss auf - ich bin eben gerade erst so einem haufen
entronnen worden..........usenet/forum - das ist mir alles einerlei!
("weihnachtsmann" in <1035825834.556325@jupiter.schunter.etc.tu-bs.de> )

Joe V. wrote:

> Apologies in advance for the newbie question ...
>
> Our project is looking into integrating EJBs into our architecture, and ha
d
> an initial design question that I was hoping someone could comment upon ..
.
>
> Our application runs on paired machine, and at any given point in time the
> application is active on one machine.  There are multiple scenarios that a
re
> transactions, and one of the main goals of switching to an EJB architectur
e
> is for the transaction models.
>
> What's the best way to keep the transaction states across the machines?
> Everything I read discourages using persistent session beans, but that's
> basically what we need.  I cannot seem to find a good design pattern to
> address this problem either (client tokens is not feasible as we have 3
> different types of clients, and storing any state on the client would be
> expensive and difficult to maintain).
>
> Any help, advice or pointers would be appreciated!

You should be looking at the capabilities of application servers rather
than stretching EJB designs in ways they don't like.  There are
distributed application servers and application servers with failover
capabilities, one or both of which might be what you really need.
WebSphere and WebLogic would be the two app servers I would look at
first if this is what you want to do, as both have been doing it
successfully for a long time.

To avoid problems as much as possible, though, I would work on designing
the system so that transactions are as finely grained as is possible
while still ensuring data and application state integrity.  It ought to
be possible to set things up without failover, a distributed container,
or persistent sessions (the last of which you might not be able to
achieve at all on any particular app server) if you are willing to force
rollback of transactions that remain incomplete when you switch servers.


John Bollinger
jobollin@indiana.edu