Menu
▾
▴
Re: [Springframework-developer] OJB support
|
From: <jue...@we...> - 2004-07-05 14:44:32
|
On the occasion, a significant difference to Hibernate that I noticed: = All of OJB's included ObjectCache implementations cache the persistent = objects themselves; all PersistenceBrokers receive shared references to = cached objects. This is of course very fast but obviously just safe for = read-only objects; there doesn't seem to be support for a transactional = read-write cache yet. iBATIS SQL Maps and TopLink work the same way in terms of caching. In = TopLink, this is the reason why you need to clone an object before = attempting to manipulate it. Of course, Hibernate's rebuilding of object = graphs on every load causes overhead (quite significant for large object = graphs!), but it does have the benefit of independent copies in each = Hibernate Session, without the potential for side effects like dirty = reads. JDO implementations have to stick to Hibernate's semantics when = providing a second-level cache: A PersistenceManager is required to = always work with independent instances by the JDO spec. It seems to me = that "transparent persistence" tools (that perform automatic change = detection on every loaded object) need to work that way, while pure = object/relational mappers (with explicit store calls) can more easily = use shared object instances in a read-only cache. Thoughts? Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Monday, July 05, 2004 2:18 PM To: spr...@li... Subject: Re: [Springframework-developer] OJB support Haven't had much time yesterday evening; gonna go through the reworked = Petclinic tonight, having it committed by tomorrow morning. Works nicely, so far: Switching between Hibernate, OJB's = PersistenceBroker and JDBC is just a change in web.xml's = "contextConfigLocation - on the exact same data model! OJB's PersistenceBroker is actually a good fit for Petclinic's data = access needs: nice mapping capabilities, but no automatic change = detection (which Petclinic doesn't need anyway). Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Sunday, July 04, 2004 3:34 PM To: spr...@li... Subject: Re: [Springframework-developer] OJB support I've just finished Petclinic's data access layer: took just about 4 = hours, mainly to get the entity relationship mappings right. I've also = retested that Petclinic still runs nicely on Hibernate, OJB and JDBC - = with the exact same data model. I'll commit the reworked Petclinic = tonight. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Sa 03.07.2004 12:58 An: spr...@li... Betreff: Re: [Springframework-developer] OJB support I've just finished all remaining OJB support infrastructure features: = PersistenceBrokerTransactionManager can expose JDBC transactions now, = there's a PersistenceBrokerDaoSupport class, and there's a = LocalDataSourceConnectionFactory helper that allows to use a = Spring-managed DataSource bean as OJB connection factory. LocalDataSourceConnectionFactory works with a static field, which is = clearly not ideal but forced by OJB's static initializer model. The OJB = guys told me that they are gonna address this for OJB 1.1, so the = current implementation is hopefully just an intermediate solution. Note that an "Open PersistenceBroker in View" pattern is not necessary = with OJB: It simply fetches a new Connection for lazy loading rather = than depending on the original PersistenceBroker still being open. I've = not actually tested this, but it was pointed out in the TSS thread. I'll provide an OJB data access implementation for Petclinic in the = course of this weekend, as an example for OJB PersistenceBroker = integration. I don't assume that this is more than 4 hours of work. I'll = also verify the lazy loading assumptions there. Furthermore, I'll = provide a test suite for the OJB support in the course of next week. The only further JAR that we need to ship for building the OJB = integration and running the sample should be db-ojb-1.0.0 jar (~800 KB). = I guess that's OK for the -with-dependencies download. It is certainly = desirable to show that we support OJB out-of-the-box just like = Hibernate. Early feedback welcome :-) Juergen ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Fr 02.07.2004 21:02 An: spr...@li... Betreff: [Springframework-developer] OJB support Hi everybody, On the occasion of the recent TSS thread on OJB 1.0 final, I've decided = to give OJB PersistenceBroker integration a go. I've already committed = the initial bunch a couple of hours ago, providing = PersistenceBrokerTemplate, PersistenceBrokerTransactionManager, etc. This initial stuff took just about 4 hours, including getting OJB to = work with a simple example! I was pleasantly surprised by how easy OJB = is to set up. I'm not fond really fond of its static initializer model, = but it does work and is simple enough to get going. I'm currently working on support for exposing the JDBC Connection in = PersistenceBrokerTransactionManager and other refinements. I plan to add = a Petclinic data access version for OJB this weekend: As far as I can = judge at this point of time, this should be simple enough to do. One of the distinct characteristics of OJB's PersistenceBroker is that = it offers all of OJB's mapping and querying capabilities, but does not = attempt to provide object-level transactions, i.e. does not do automatic = change detection but rather rely on explicit store calls. For = Petclinic-style web apps, this is more than enough. The stuff in CVS does work already, so whoever's interested, feel free = to have a look at it :-) Juergen ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20 digital self defense, top technical experts, no vendor pitches,=20 unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20 digital self defense, top technical experts, no vendor pitches,=20 unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
