Modelling persistent data with stateful session beans

Hi,

we are having discussion in our development team about choosing the
right bean type for our business data. The data in question is a list
of open orders for a product. There are two proposals on the table:

1) Stateful session bean (the state representing the data, ie. the
product number and the list of orders for the product)

2) Entity bean (containing the product number and the order list, ie.
coarse-grained)

We assume in both cases the bean would handle its persistence itself
(BMP for the entity bean).
For the entity bean we assume it would NOT be clusterable (because we
want to minimize ejbLoads() and access it always thru the local
interface).

The argument pro stateful session bean is this: we can turn on
in-memory replication in a cluster, making sure there is always a copy
of the bean on some other node, should a particular cluster node
crash.

The argument pro entity bean is that failover is easy because we only
need to perform ejbLoad on a stand-by node that would be activated in
the case of a node failure.

The arguments con stateful session bean are these:
- although the replication can be set only upon commit for stateful
session beans, there is no real guarantee as the server crash can
happen AFTER the transaction commits (hence the bean persists itself)
but BEFORE the state gets replicated
- another question arises whether the stateful session bean should
persist itself on ejbPassivate()? Maybe it gets only swapped-out but
would be eventually swapped-in later and the round-trip to the
database is unnecessary.
On the other hand, what if the stateful session bean times out?

The arguments con entity beans are these:
- can we avoid expensive ejbLoad on a begin of a transaction? We opt
for non-clusterable entity beans for the very reason that they would
entail this ejbLoad on a begin of a transaction. However, we are not
SURE SURE that using non-clusterable entity beans (ie. with
non-clusterable home interface) prevents ejbLoads from happening.

I would welcome any critism, comments and recommendation to our design
contemplations.

Thanks,

Dusan

Dusan Chromy wrote:
> we are having discussion in our development team about choosing the
> right bean type for our business data. The data in question is a list
> of open orders for a product. There are two proposals on the table:
>
> 1) Stateful session bean (the state representing the data, ie. the
> product number and the list of orders for the product)
>
> 2) Entity bean (containing the product number and the order list, ie.
> coarse-grained)
>
> We assume in both cases the bean would handle its persistence itself
> (BMP for the entity bean).

Stateful session beans don't have anything *conversational* state.
There's no BMP involved in session beans.

--
Darryl L. Pierce <mcpierce@gmail.com>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard

Darryl L. Pierce wrote: 
>
>
> Stateful session beans don't have anything *conversational* state.

This is not true. Stateful Session Beans do have a conversational state
with the client. What you have to decide: is it necessary to hold a
state on the server (e.g. if several ejb methods are called in
rotation). The second decision is persistence (CMP, BMP, other
persistence engine like Hibernate).

-m

Marek Lange wrote:
 
>
> This is not true. Stateful Session Beans do have a conversational state
> with the client.

My bad. I meant "don't have anything _BUT_ *conversational* state." My
bad for not typing what I was saying.

I just had this same conversation with a guy at work a few ws ago. He
was swearing up and down that stateful session beans can be either CMP
or BMP and would not listen when I told him they *don't* have DB
persistence but just conversational persistence. When I showed him in my
copy of _Enterprise Java Beans_ where it's explained, he claimed my book
was an "old version" (it's the latest revision from O'Reilly) and that
he was right.

--
Darryl L. Pierce <mcpierce@gmail.com>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard

"Darryl L. Pierce" <mcpierce@gmail.com> wrote in message news:<eDjpd.45565$z3.3585@bignews5
.bellsouth.net>...
> Dusan Chromy wrote: 
>
> Stateful session beans don't have anything *conversational* state.
> There's no BMP involved in session beans.

I fully agree there's no BMP with session beans. I wrote we'd be using
BMP for entity beans, whereas the idea with session beans is to use
the "conversational state" for the business data (product number and
order list). Some developers feel this is a good idea while some feel
completely otherwise. Unfortunately we have little experience under
the belt, that's why I'm posting the message here.

"Darryl L. Pierce" <mcpierce@gmail.com> wrote in message news:<rekpd.45566$z3.10589@bignews
5.bellsouth.net>...
> Marek Lange wrote:
> 
>
> My bad. I meant "don't have anything _BUT_ *conversational* state." My
> bad for not typing what I was saying.
>
> I just had this same conversation with a guy at work a few ws ago. He
> was swearing up and down that stateful session beans can be either CMP
> or BMP and would not listen when I told him they *don't* have DB
> persistence but just conversational persistence. When I showed him in my
> copy of _Enterprise Java Beans_ where it's explained, he claimed my book
> was an "old version" (it's the latest revision from O'Reilly) and that
> he was right.

Yes, I supposed you ommited "BUT" in that sentence, Darryl. And there
is no such thing as CMP for stateful session beans. Yet you can
persist the conversational state in the bean itself. Actually it's
fully up to you what state the bean has - it is INTENDED for
conversational state, but you can use it for business data -
concretely orders in our project. Which are database objects.

Now the discussion goes "can stateful beans have CMP/BMP?". I fully
agree: no. What I ask is this:

What problems arise when you use the conversational state for your
business data (orders)? Should we avoid doing that? Should we do that?

Dusan Chromy wrote:
> Hi,
>
> we are having discussion in our development team about choosing the
> right bean type for our business data. The data in question is a list
> of open orders for a product. There are two proposals on the table:
>
> 1) Stateful session bean (the state representing the data, ie. the
> product number and the list of orders for the product)
>
> 2) Entity bean (containing the product number and the order list, ie.
> coarse-grained)
>
> We assume in both cases the bean would handle its persistence itself
> (BMP for the entity bean).
> For the entity bean we assume it would NOT be clusterable (because we
> want to minimize ejbLoads() and access it always thru the local
> interface).
>
> The argument pro stateful session bean is this: we can turn on
> in-memory replication in a cluster, making sure there is always a copy
> of the bean on some other node, should a particular cluster node
> crash.
>
> The argument pro entity bean is that failover is easy because we only
> need to perform ejbLoad on a stand-by node that would be activated in
> the case of a node failure.
>
> The arguments con stateful session bean are these:
> - although the replication can be set only upon commit for stateful
> session beans, there is no real guarantee as the server crash can
> happen AFTER the transaction commits (hence the bean persists itself)
> but BEFORE the state gets replicated
> - another question arises whether the stateful session bean should
> persist itself on ejbPassivate()? Maybe it gets only swapped-out but
> would be eventually swapped-in later and the round-trip to the
> database is unnecessary.
> On the other hand, what if the stateful session bean times out?
>
> The arguments con entity beans are these:
> - can we avoid expensive ejbLoad on a begin of a transaction? We opt
> for non-clusterable entity beans for the very reason that they would
> entail this ejbLoad on a begin of a transaction. However, we are not
> SURE SURE that using non-clusterable entity beans (ie. with
> non-clusterable home interface) prevents ejbLoads from happening.

I think some of your arguments are focusing in the wrong places.  If you
decide upon an architecture that does not model your data and business
processes well then you are likely to run into problems much more
serious than how many times entity beans are loaded.

Using stateful session beans to imitate entity beans is a bad idea, as
entity beans already provide about the right functionality for what they
do.  Instead, the choice should be between entity beans and some other,
lighter-weight data access objects.  You can, and probably should, put a
_stateless_ session bean in front of whichever data access mechanism you
choose: large among the benefits is that you can later change out the
business data access and persistence mechanism without affecting the
business logic on top.


John Bollinger
jobollin@indiana.edu

"John C. Bollinger" <jobollin@indiana.edu> wrote in message news:<cofief$48s$1@hood.uits.in
diana.edu>...
>
> I think some of your arguments are focusing in the wrong places.  If you
> decide upon an architecture that does not model your data and business
> processes well then you are likely to run into problems much more
> serious than how many times entity beans are loaded.
>
> Using stateful session beans to imitate entity beans is a bad idea, as
> entity beans already provide about the right functionality for what they
> do.  Instead, the choice should be between entity beans and some other,
> lighter-weight data access objects.  You can, and probably should, put a
> _stateless_ session bean in front of whichever data access mechanism you
> choose: large among the benefits is that you can later change out the
> business data access and persistence mechanism without affecting the
> business logic on top.
>
>
> John Bollinger
> jobollin@indiana.edu

Cheers John. I actually disliked the idea of imitating entity beans
via SFSB and I like your idea of using a session facade to hide the
implementation details. As the old saying goes, an extra level of
indirection solves every problem in computer science :-)