Re: [JBoss-user] stateless session beans cannot call statefulsession beans!!?
Hi David,
I have a non-transactional SQL datasource (legacy). I am trying to
update it as transactionally as possible. Using afterComplete() in a
SFSB that implements SessionSynch. works pretty damn well (it is
guaranteed that ALL the other datasources have committed).
Anyhow, I got a fairly neat solution to the problem from a guy on
EJBinterest (Doug Bateman). He suggested I pass the SFSB in to the
SLSB, so someone else can handle the remove (a SFSB).
e.g. SFSB1 creates and caches SFSB2, and when it calls SLSB1, it passed
the local ref to SFSB2 in as an arg, this allows SFSB1 to do an
ejbRemove on SFSB2 when it's own remove() gets called.
Thanks for the input.
Craig
On Sun, 2002-07-21 at 01:09, David Jencks wrote:
I don't understand what you are trying to do. Why not update the
datasource when the data changes?
If you are trying to write a cache that flushes at the end of the tx,
notified by a synch, I don't think session beans are necessarily an
appropriate solution. JDO has this problem also, and I don't think there
is a good solution. It's mentioned in appendix C of the jca spec in an
un-implementable way.
I think the way to do it is to write a jca adapter that exposes some
transactional interface and knows about the tx manager. When its tx
interface (LocalTransaction or XAResource) is informed of a new tx, it can
register a synch with the tx manager so it can flush on beforeCommit().
Currently the JDO spec sidesteps this solution by requiring you to close
your jdo persistence managers (connection handles) inside the tx, which is
the trigger for the flush operation.
david jencks
On 2002.07.16 21:42:46 -0400 Craig O'Shannessy wrote:
On Wed, 2002-07-17 at 00:43, Maris Orbidans wrote:
Start a new transaction with someMethod(accountNumber1,amount) method.
I think then the SFSB will be removable because it will not be
participating in any transaction.
This is true, but doesn't actually help what I am trying to do. I need
to update a non-transactional datasource, and the best way to do this
seems to be to use SessionSynchronization, (which can ONLY be used on
SFSB's). The update needs to be part of the outer transaction. This
seems to preclude the use of ANY SLSB's anywhere between the original
client call and the SFSB doing the SessionSynchronization. This seems
like a nasty, dangerous and undocumented restriction.
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
I am not sure that it means that instances of SLSB are reentrant.
(spec. 7-11-8)
Maris
-Original Message-
From: Craig O'Shannessy [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 16, 2002 12:15 PM
To: jboss-user
Subject: [JBoss-user] 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
RE: [JBoss-user] stateless session beans cannot call statefulsession beans!!?
On Wed, 2002-07-17 at 00:43, Maris Orbidans wrote:
Start a new transaction with someMethod(accountNumber1,amount) method. I think then
the SFSB will be removable because it will not be participating in any transaction.
This is true, but doesn't actually help what I am trying to do. I need
to update a non-transactional datasource, and the best way to do this
seems to be to use SessionSynchronization, (which can ONLY be used on
SFSB's). The update needs to be part of the outer transaction. This
seems to preclude the use of ANY SLSB's anywhere between the original
client call and the SFSB doing the SessionSynchronization. This seems
like a nasty, dangerous and undocumented restriction.
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
I am not sure that it means that instances of SLSB are reentrant. (spec. 7-11-8)
Maris
-Original Message-
From: Craig O'Shannessy [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 16, 2002 12:15 PM
To: jboss-user
Subject: [JBoss-user] 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.
---
This sf.net email is sponsored by: Jabber - The world's
fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
---
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
