Chandan, thank you for your assistance. Your PersistA corresponds to my EJBA
class in the example below. Persistency calls is delegated to EJBA by the
event propagation. Container managed persistence ensures that the attribute
is persisted in EJBA.
J�rn
-----Original Message-----
From: Chandan Singh [mailto:[EMAIL PROTECTED]]
Sent: Saturday, August 28, 1999 8:53 AM
To: [EMAIL PROTECTED]
Subject: Re: Unwanted re-entrancy
What if you use a different class (say PersistA) to
encapsulate the persistency mechanism for the Class A
and delegate the persistency calls to this class.
This class could also act as a property change
listener for persistent attribures of class A.
This should take care of the reentrancy problem and
also enable to separate the persistency mechanism
from your business logic making class A easily
portable to any infrastructure.
-Chandan
---Jorn Leonhardsen wrote:
>
> I hope somebody can help me on the following problem;
>
> My core business logic is implemented by means of
Java code which is intended to run in different
middleware frameworks like EJB and COM/MTS.
Consequently, there is no knowledge in this Java code
about which specific framework to be used to make the
code remote enabled, transactional etc.
>
> The following example illustrates a pattern for how
to EJB-enable code which is EJB-unaware.
>
> The core class A has a businessmethod doSmth()
which - when executed - results in the change of the
attribute someAttribute. This attribute is
persistent. The EJB class EJBA is a wrapper of class
A to remote-enable the business method, provide
automatic persistence under transaction control. The
persistent attribute of A - someAttribute - is
mirrored in EJBA and EJBA delegates the business
method call doSmth to A which in turn fires
propertyChangeEvents when the property someAttribute
is changed.
>
> The class PropagateEventsFromAtoEJBA implements
propertyChangeListener and has the responsibility of
routing propertyChangeEvents from A to EJBA to ensure
that attributes are persisted.
>
> The classes EJBA and PropagateEventsFromAtoEJBA are
- in other words - classes required to EJB-enable the
EJB-unaware class A.
>
> The connection between A and EJBA is constructed in
EJBA in the following way when EJBA is created or
loaded:
>
> -Instantiate A and set its persistent attributes
> -Instantiate PropagateEventsFromAtoEJBA, provide it
with the PrimaryKey of EJBA and EJBAHome and register
it as a propertyChangeListener of the A instance
>
>
> class A{
> .
> .
> int someAttribute;
> .
> void doSmth(){
> update someAttribute;
> firePropertyChangeEvent();
> }
> .
> .
> }
> class EJBA implements EntityBean{
> //This class is an EJB wrapper of A
> //Business methods is delegated to A
>
> int someAttribute; //Mirror of aRef.someAttribute
> A aRef; //Reference to core class
> .
> .
> //The business method doSmth. Delegates to aRef
> void doSmth() throws RemoteException{
> aRef.doSmth();
> }
>
> //This method is used by the
PropagateEventsFromAtoEJBA class to
> //prograte the propertyChangeEvent from A to EJBA
> void propertyChange(PropertyChangeEvent pce){
> //Use pce to find changed attribute and assign the
> //new value to the mirrored attribute in EJBA
>
> }
>
> .
> .
> }
>
> Now the problem: The design ensures that a
persistent property being changed
> in aRef.doSmth is updated in the EJBA.doSmth before
this method returns, i.e. it is persisted within the
transaction context of the EJBA.doSmth method. The
following chain of method invocations takes place
before EJBA.doSmth returns:
>
EJBA.doSmth->A.doSmth->PropagateEventsFromAToEJBA.propertyChange->EJBA.prope
rtyChange
>
> One major downside of this approach is that i
requires the enterprise bean to be re-entrant.
>
> Can anybode provide an alternative, re-entrant free
solution to this problem, still ensuring that the
attributes are persisted within the EJBA.doSmth method?
>
> Thanks in advance,
> J�rn Leonhardsen
>
>
===========================================================================
> 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".
>
>
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
===========================================================================
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".
