Can you point out where yor previous answer is, quote it, or explain to me why? (I looked but couldn't find it) Thanks.
Part of my "quest for the holy grail", is that no logical object should ever exist as two different Java instances (at the same time). I have, at least for the moment, the luxury of living in a single JVM. David Mahler Thomas wrote: >Hi again, > >As mentioned in my previous answer, there are situation where it is not safe >to rely on instance *identity* after a lookup. > >you should build you apps in a way that they only rely on *equivalence*. > >see a sample testcase: >http://jakarta.apache.org/ojb/xref/org/apache/ojb/broker/PersistenceBrokerTe >st.html#523 > >cheers, >Thomas > > > >>elhar, Wallace J. wrote: >> >> >> >>>Frank, >>> >>>As stated in another email, the cache uses weak references. >>> >>> >>This means >> >> >>>that if you create the object, release your reference (At >>> >>> >>this point is >> >> >>>it fair game for garbage collection). \Then subsequently load the >>>object, OJB will check the cache and if not present will >>> >>> >>load from the >> >> >>>DB and create a new object with the same OID (and obviously data >>>values). I am not an expert, but I believe it's always a >>> >>> >>good idea to >> >> >>>overload .equals on your business objects anyways for >>> >>> >>comparison in your >> >> >>>applications. >>> >>> >>> >>> >>I'm talking about an IMMEDATE load write after creating, and while >>holding the original object still. This was something I >>noticed while >>debugging a problem in some test code. >> >> >> >>-- >>To unsubscribe, e-mail: >><mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: >><mailto:[EMAIL PROTECTED]> >> >> >> > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
