RE: [Springframework-developer] OJB PB Support: Why only partial?

[Clute, A. <And...@os...>]

Juergen,
=20
Thanks for the quick feedback!
=20
After reading your message, I now have a much better understanding about =
the pattern for using the Callbacks. Based on that, you are correct, =
methods like getClassDescriptor are part of a larger, interrelated set, =
and should use a Callback -- I am using it to implement my own deep save =
and deep cache removal, which allows me to do it programmatically, =
versus declaratively with the repository.xml.=20
=20
The one statement you did make sort of put what I thought to understand =
about using the PBTemplate in question -- "
This is particularly recommendable for operations that involve multiple =
interrelated PersistenceBroker calls. Any such callback will =
automatically participate in Spring's resource and transaction =
management, just like the convenience operations do."
=20
My understanding is that by using the =
PersistenceBrokerTransactionManager, the life of my request (web =
request) that is tied to a thread, will be tied to a single =
PersistenceBroker instance. And more importantly, based upon my TX =
declarations, will happen inside the same TX as well. At the same time =
when the request is finished, it will also close the PB instance. Is =
this an accurate understanding?
=20
Thanks!
-Andrew
=20

________________________________

From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of j=FCrgen h=F6ller [werk3AT]
Sent: Tuesday, August 31, 2004 10:34 AM
To: spr...@li...
Subject: Re: [Springframework-developer] OJB PB Support: Why only =
partial?


Indeed, the convenience operations on PersistenceBrokerTemplate are just =
a subset. Note that you can always implement your own =
PersistenceBrokerCallback, working with the raw PersistenceBroker. For =
example:
=20
Object myObject =3D getPersistenceBrokerTemplate().execute(new =
PersistenceBrokerCallback() {
  public Object doInPersistenceBroker(PersistenceBroker pb) {
    return pb.getObjectByIdentity(new Identity(...));
  }
});
=20
This is particularly recommendable for operations that involve multiple =
interrelated PersistenceBroker calls. Any such callback will =
automatically participate in Spring's resource and transaction =
management, just like the convenience operations do.
=20
If there are further typical convenience operations that make sense on =
PersistenceBrokerTemplate itself, I'm open to adding them:
=20
* getReportQueryIteratorByQuery is an obvious candidate. I've just added =
it.
=20
* getObjectByIdentity does not seem to be intended for direct usage, =
according to the OJB javadocs. The main issue is: Where do you get the =
Identity parameter from? As this is unlikely to come in from the =
outside, it's probably appropriate to just use getObjectByIdentity as =
part of a sequence of calls within a PersistenceBrokerCallback.
=20
* getClassDescriptor seems like a method typically used as part of a =
larger sequence too, so also rather to be used within a =
PersistenceBrokerCallback.
=20
If I'm wrong in terms of the typical use cases for the latter two, feel =
free to try to convince me :-)
=20
Juergen
=20
=20

	-----Original Message-----
	From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Clute, Andrew
	Sent: Tuesday, August 31, 2004 4:06 PM
	To: spr...@li...
	Subject: [Springframework-developer] OJB PB Support: Why only partial?
=09
=09

	Since the release of 1.1RC2, I have been attempting to retrofit Spring =
into my system and remove my EJB's. We make heavy use of OJB's =
PersistenceBroker API, and as such, I was hoping to utilize the =
PersistenceBrokerDaoSupport, with the PersistenceBrokerTemplate.=20

	However, it seems that PersistenceBrokerTemplate only supports a subset =
of the methods that PB has on it, with the three major missing ones =
being findObjectByIdentity, getReportQueryIteratorByQuery and =
getClassDescriptor.

	Was there a conscious decision to leave these methods out, or was it =
just an oversight/timing issue? I would be happy to implement these =
methods and submit the changes back to the group, but I wanted to =
confirm that there wasn't a specific reason for leaving these off.

	Thanks!=20

	-Andrew=20