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. -----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]
