>From the section you pointed out , At first glance I think its not talking
about remove on any other statefull bean.
Again using the reference for statefull session bean in stateless session
bean is meaningless. As you have pointed out.
Cheers
Ashwani
----- Original Message -----
From: "Craig O'Shannessy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 16, 2002 2:52 PM
Subject: stateless session beans cannot call stateful session beans!!?
> Hi,
>
> I wonder if someone could clear up a problem for me. It seems that a
> Stateless session bean cannot really use a Stateful session bean for
> two reasons.
>
> 1. The stateless bean cannot call remove on the stateful, therefore can't
> clean it up (see code below)
>
> 2. If the stateless bean holds onto a reference to a stateful bean to get
> around creating one on each call and avoid problem 1., another problem
> occurs. The Stateless bean can be shared between concurrent
transactions
> (see quote from spec below), therefore the stateful beans transactional
> scope is indeterminate (cause nasty blocking or even overlapping
> transactions?)
>
> One reason you might want to use a Stateful bean from a Stateless is to
> do SessionSyncronization on a non transactional datasouce for example.
>
> --------- Code example for problem
1. --------------------------------------
> /**
> * For readability, this example uses xdoclet code, if you don't use it,
> * you might want to check it out!
> */
> class StatelessBean extends SessionBean
> {
> /**
> * @ejb:interface-method
> */
> public void transferMoney(long account1,long account2,double amount)
> {
> StatefulEJBLocal stateful =
StatefulEJBUtil.getLocalhome().create();
> stateful.someMethod(accountNumber1,amount);
> // stateful.remove(); <-- Can't do this, RemoveException
> // (7.5.7 p79 ejb2 spec)
> }
> }
> --------------------------------------------------------------------------
----
> Quote from Section 7.8, p87 of ejb2 spec
>
> Because all instances of a stateless session bean are equivalent, the
> container can choose to delegate a client-invoked method to any available
> instance. This means, for example, that the Container may delegate the
> requests from the same client within the same transaction to different
> instances, and that the Container may interleave requests from multiple
> transactions to the same instance.
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
