Hi again,
here is some pseudo code:
public abstract class NestedActivityImpl implements Activity
{
/**
* The broker instance reposible for persistence work.
* May be null for nested activities.
*/
transient private PersistenceBroker broker = null;
/** The activities parent activity, may be null!*/
private Activity parentActivity = null;
/**
* checks whether this is a root activity. root activities have no
parent activity
* and are allowed to access transactions.
* @return boolean
*/
private boolean isRootActivity() throws RemoteException
{
return (getParentActivity() == null);
}
/** returns the parent Activity. returns null if no parent is set*/
public final Activity getParentActivity() throws RemoteException
{
return parentActivity;
}
/**
* Start a Transaction.
*/
public void beginTransaction() {
// only RootActivities are allowed to start Transactions
if (isRootActivity())
{
getBroker().beginTransaction();
}
// subactivities can't trigger Transactions !
else
{
}
}
/**
* commit a Transaction.
*/
public void commitTransaction() {
// only RootActivities are allowed to commit Transactions
if (isRootActivity())
{
getBroker().commitTransaction();
}
// subactivities can't commit Transactions !
else
{
}
}
/**
* returns the Broker of the Activity.
* If it is a root activity it has it's own broker, which is returned.
* A nested activity has no own transaction context, so the broker
of the
* parent activity is returned. (nesting may be recursive !)
* @return PersistenceBroker the associated PersistenceBroker
*/
public synchronized PersistenceBroker getBroker()
{
if (isRootActivity())
{
if (broker == null)
{
broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
}
return broker;
}
else
{
return getParentActivity().getBroker();
}
}
}
I hope this get's you started!
> -----Original Message-----
> From: Shane Mingins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 11, 2003 12:45 AM
> To: 'OJB Users List'
> Subject: RE: How do I Select for Update, Select for Read without
> duplicati on?
>
>
> Hi Thomas
>
> Thanks for that. I think I actually understand what you mean :-)
>
> Would you have any code examples of this anywhere that I
> could through?
>
> Cheers
> Shane
>
> P.S. And yes, I wondered if this sort of pattern is in the
> book P of EAA,
> it's on my list of books to order.
PEAA is a must have book! It gives alot of details on the architecture of
O/R mapping tools.
You'll find many things that map directly to patterns used in OJB!
I just checked the table of contents, but I think the "NestedActivity"
pattern is not covered in PEAA.
But Google will give you some hints, ...
cheers,
Thomas
>
> -----Original Message-----
> From: Thomas Mahler [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 10 June 2003 6:17 p.m.
> To: OJB Users List
> Subject: Re: How do I Select for Update, Select for Read without
> duplication?
>
> Hi Shane,
>
> Here is is a pattern that I'm using:
> I call it NestedActivitity.
> A NestedActivity may be a toplevel activity, that is, it's parent ==
> null. Or it may be a sub-activity with a parent != null.
>
> NestedActivity has methods begin() and commit().
> if parent == null begin() opens a transaction.
> if parent == null commit() commits the transaction.
>
> This trick prevents the child activities to directly access
> transactions.
> This trick also allows to have arbitrary nestings of business
> activities.
>
> I don't know if this is a pattern that is already listed somewhere,
> maybe in one of Martin Fowlers books.
>
> cheers,
> Thomas
>
>
> Shane Mingins wrote:
> > H
> >
> > I am using the OJB ODMG API with an application and I am
> wondering what
> > people end up doing to avoid lots of code duplication for CRUD type
> > activities.
> >
> > If I am doing a CREATE I can create an instance of a new
> object and pass
> > that object to a store(object) method that can:
> > 1. open (if not already) an OJB connection
> > 2. start a transaction
> > 3. persist the object
> > 4. commit the transaction
> >
> > If I am going to READ the object I can call a read(objectKey) method
> passing
> > the object key etc:
> > 1. open (if not already) an OJB connection
> > 2. start a transaction
> > 3. create and execute my query, i.e. get the object
> > 4. commit the transaction
> > 5. return the object
> >
> > But if I am doing an UPDATE I need to be able to read the
> object, make
> > changes, and persist the changes within a single
> transaction. Therefore I
> > cannot just reuse my read and store methods.
> >
> > Ideally I would like to call a getObject() method on an
> object manager
> class
> > and have it read or create and update.
> >
> > For example:
> >
> > CustomerManager mgr = CustomerManager.get();
> > Customer customer = mgr.getCustomer(name); // this either
> creates a new
> > customer or returns existing
> >
> > ... do some stuff to the customer object ....
> >
> > mgr.store(customer); // this will either persist a new
> customer or update
> > an existing
> >
> > The key seems to be how to start/abort/commit transactions
> around the CRUD
> > actions. I was using the join method on the transaction
> object but I am
> not
> > sure if that is a good approach or not.
> >
> > Can anyone share some advice or perhaps resource that
> addresses my queries
> > in more detail than outlined in the tutorials? I am
> guessing that there
> is
> > some design pattern that perhaps address this but if it is
> too abstract
> (as
> > a lot of patterns are) I get lost applying it to my actual
> situation.
> >
> > Thanking You in Advance
> > Shane
> >
> > Shane Mingins
> > Analyst Programmer
> > Assure NZ Ltd
> > Ph 644 494 2522
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
