Return-Path: Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm Delivered-To: mailing list ojb-dev@db.apache.org Received: (qmail 50769 invoked from network); 1 Apr 2003 16:16:17 -0000 Received: from nsesn2.itellium.de (194.145.89.2) by daedalus.apache.org with SMTP; 1 Apr 2003 16:16:17 -0000 Received: from f9620014.itellium.com (f9620014.itellium.com [10.0.6.31]) by nsesn2.itellium.de (Itellium SYSTEMS & SERVICES GmbH) with SMTP id h31GGHa20196 for ; Tue, 1 Apr 2003 18:16:17 +0200 Received: from unknown(10.200.203.10) by f9620014.itellium.com via csmap id 22821; Tue, 01 Apr 2003 18:13:26 +0200 (CEST) Received: by f94000r7.essen.karstadt.de with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 18:15:58 +0200 Message-ID: From: Mahler Thomas To: "'OJB Developers List'" Subject: RE: I'm disturbed... Date: Tue, 1 Apr 2003 18:16:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi David, > > Yes, this is a repost. I posted this comment (and submitted > a bug (152, I > think)) in the middle of last week. It seems rather serious > to me. The > disturbing part is there has been no reply at all to a > problem where data > is NOT stored (when it should be, I think). I'm very familiar with > open-source and the volunteer nature of open-source projects, so I > certainly don't expect "12 hour turn around on bug fixes" or anything. > But, when you're in the RC stage of a project, and someone > identifies the > explicts of a bug and asks for help with a tactical direction > to fix it, I > think *some* response is warranted... *SORRY* I spend last weekend with assembling the rc2 release... I'll hope to work on your issue this week. thanks for your patience, Thomas > Thanks > David > > > > |---------+---------------------------> > | | David.Corbin@equ| > | | ifax.com | > | | | > | | 03/26/2003 04:23| > | | PM | > | | Please respond | > | | to "OJB | > | | Developers List"| > | | | > |---------+---------------------------> > > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| > | > > | > | To: "OJB Users List" > > | > | cc: ojb-dev@db.apache.org > > | > | Subject: Re: Non-Decomposed collections, without > implicit locking > | > | > > | > > >------------------------------------------------------------- > -------------------------------------------------------------- > -----------------------| > > > > > Please consider this snippet from the ObjectEnvelope#getMap (Revision > 1.17). > > if (items != null) > { > // items might be a Collection or an array. > if (items instanceof Collection) // [A] > { > /* > * if items are a collectionproxy, and > it's not already > loaded, don't register it. > */ > if (!( items instanceof CollectionProxy) || > ( (CollectionProxy) items).isLoaded()) //[B] > { > continue; > } > /** > * MBAIRD > * size isn't the safest thing to use as > the dirty bit. > This will > * need to be fixed. > */ > Object dirtyMark = new > Integer(((Collection)items).size > ()); > fieldValues.put(collectionDescriptor, dirtyMark); > } > else // items instanceof Object[] > { > Object dirtyMark = new Integer(items.hashCode()); > fieldValues.put(collectionDescriptor, dirtyMark); > } > > > In Revision 1.17 has introduced a bug. The CVS metadata says > this is in > response to BUG OJB131. I think addiition of line [A} is > perfectly proper. > However, the meaning of the condition on line [B] has been totally > reversed. (Honest! I did a truth table). The consequences > are very bad for > users of Non-Decomposed Collections (that's where we have problems --- > might be problem in other Collections). > > Additionally, the comment about using size as the dirty bit > is extremely > frightening to me, as that indicates a measurable quantity of > changes to a > collection just won't be persisted. > > I have a proposal to change the dirty-bit part of the code, > but it involves > adding another method to the ManageableCollection interface. > Essentially, > make it the responsibility of the collection to provide a digest (or > something similar) that can be used as a dirt bit. I'll be > glad to right > it if you think that's an OK plan. If not, the only solution > I can see is > to iterate over the list, building maps of each individual > object, and then > making sure this collection of maps implements equals correctly. > > As we're weeks away from our deadline, anything I can do to get this > working "correctly", let me know. > > David > > > > |---------+---------------------------> > | | David.Corbin@equ| > | | ifax.com | > | | | > | | 03/26/2003 10:39| > | | AM | > | | Please respond | > | | to "OJB Users | > | | List" | > | | | > |---------+---------------------------> > > > -------------------------------------------------------------- > -------------------------------------------------------------- > ----------------------| > > | > | > | To: ojb-user@db.apache.org > | > | cc: > | > | Subject: Non-Decomposed collections, without > implicit locking > | > | > | > > > -------------------------------------------------------------- > -------------------------------------------------------------- > ----------------------| > > > > > We've been using ND collections, and without realizing it, we > had implicity > locking turned out. > > It worked great in 0.9.9. > > However, when we switched turned off implicit locking, and > switched to rc1, > objects in the ND collection are not persisted. > > Experimentation reveals this doesn't work in 0.9.9 w/o > implicit locking, > and doesn't work in rc1 with or without implicity locking. > > I've not yet debugged into OJB to see what it is doing, but > I'm planning on > it. > > Should this work still? Is anyone else having problems in this area? > > David > > > This message contains information from Equifax Inc. which may be > confidential and privileged. If you are not an intended > recipient, please > refrain from any disclosure, copying, distribution or use of this > information and note that such actions are prohibited. If you have > received this transmission in error, please notify by e-mail > postmaster@equifax.com. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org > For additional commands, e-mail: ojb-user-help@db.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org > For additional commands, e-mail: ojb-dev-help@db.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org > For additional commands, e-mail: ojb-dev-help@db.apache.org > >