Return-Path: Delivered-To: apmail-incubator-cayenne-user-archive@locus.apache.org Received: (qmail 31859 invoked from network); 21 Dec 2006 09:48:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Dec 2006 09:48:37 -0000 Received: (qmail 90864 invoked by uid 500); 21 Dec 2006 09:48:44 -0000 Delivered-To: apmail-incubator-cayenne-user-archive@incubator.apache.org Received: (qmail 90627 invoked by uid 500); 21 Dec 2006 09:48:43 -0000 Mailing-List: contact cayenne-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cayenne-user@incubator.apache.org Delivered-To: mailing list cayenne-user@incubator.apache.org Received: (qmail 90440 invoked by uid 99); 21 Dec 2006 09:48:43 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Dec 2006 01:48:42 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [207.210.96.236] (HELO byaroza.objectstyle.org) (207.210.96.236) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 21 Dec 2006 01:48:32 -0800 Received: (qmail 5269 invoked from network); 21 Dec 2006 09:48:11 -0000 Received: from unknown (HELO ????????IPv6:::1?) (127.0.0.1) by localhost with SMTP; 21 Dec 2006 09:48:11 -0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrus Adamchik Subject: Re: Antwort: Re: Loosing references to foreign objects -> update will fail Date: Thu, 21 Dec 2006 11:48:10 +0200 To: cayenne-user@incubator.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org Doesn't matter - it works against all stable branches (1.2, 2.0) and trunk (3.0). The one I quoted is done against the trunk. When I applied it against 1.2 I had to manually change "apache" to "objectstyle" in the file name. There was one failed piece that you can safely ignore. Also I am planning to commit it on 1.2 branch sometime today. Andrus On Dec 21, 2006, at 11:35 AM, Florian.Eska@gi-de.com wrote: > Hi Andrus, > > is your patch based on a 1.2.1 or on a 1.2 version of cayenne. > > Because we will it insert this version in our local maven > repository and we > will not wait for a official release. > > > Thanks > Florian > > > > > > Andrus Adamchik > > le.org> An > cayenne- > user@incubator.apache.org > 21.12.2006 > 09:39 Kopie > > T > hema > Bitte antworten Re: Loosing references to > foreign > an objects -> update will fail > cayenne-user@incu > bator.apache.org > > > > > > > > > Good to know that it worked - I will commit it to 1.2 and 2.0 > branches. Here is the contents of the patch: > > http://tinyurl.com/sz7fw > > In short it prevents incomplete snapshots (those that contain only PK > columns and no other data) from being stored in the shared cache. > There were other safeguards against it, but obviously they weren't > working under certain circumstances. > > Andrus > > > On Dec 21, 2006, at 10:15 AM, Florian.Eska@gi-de.com wrote: > >> Hi Andrus, >> >> so your patched jar works for us in this case. The error doesn't >> occure any >> more. >> >> So first question. >> >> What do you have changed, because we also tried the 1.2.1 version? >> >> Thanks florian >> >> >> >> >> >> Andrus Adamchik >> > >> le.org> An >> cayenne- >> user@incubator.apache.org >> 21.12.2006 >> 07:38 Kopie >> >> >> T >> hema >> Bitte antworten Re: Loosing references to >> foreign >> an objects -> update will fail >> cayenne-user@incu >> bator.apache.org >> >> >> >> >> >> >> >> >> I wonder if that's another consequence of this bug: >> >> http://issues.apache.org/cayenne/browse/CAY-724 >> >> I implemented a fix that works in my application, but I still don't >> fully understand the underlying cause of it. Still it looks like a >> suspect here too. Anyways, here is a patched 1.2 jar file that I >> uploaded here: >> >> http://people.apache.org/~aadamchik/cayenne-1.2-patchCAY-724/ >> >> Try that first and let me know if it worked. If it doesn't, next >> thing to check is the value of "Max Number of Objects" for the >> DataDomain in the Modeler (default is 10000). You may try to increase >> it to something higher. >> >> Andrus >> >> >> >> On Dec 20, 2006, at 5:52 PM, Florian.Eska@gi-de.com wrote: >>> Hallo, >>> >>> in our application we loose sometimes the reference to a mandatory >>> foreign >>> object (not null, foreign key) >>> >>> Our object relation are >>> >>> Export Container -> products >>> product -> client >>> product -> image >>> product -> state >>> >>> The problem occurs in our exporter process. It works like >>> >>> Begin Transaction >>> Select all products that are in the correct state >>> Create the export container >>> export all product information including the image blob to file >>> (read >>> the objects into the memory) >>> change the export container content >>> for each product create the following state of the process >>> (update of >>> the product row and create a new state row) >>> commit Transaction >>> >>> During the commit some of the products have no reference to a client >>> object. => Update will fail because no mandatory object reference >>> exist. >>> (org.objectstyle.cayenne.validation.ValidatiionException >>> Product.client: >>> "client" is required.) >>> The database contains the correct client relation. >>> So it will run correct if we reduce the max. exported products to >>> 100. But >>> for a other run with other data we exported 500 products per export >>> run. >>> >>> Also we have attached to the running process and so we see no memory >>> problem, because it occure if we have around 300 MB free memory in >>> the jvm. >>> >>> For a test run we also changed the implementation. So step 6 will >>> also make >>> a commit for each product update :-(. >>> The result is that we can export the first 480 products, than we >>> got the >>> error. Than we have additional product in the correct state to >>> export. So >>> we will export in the example 180 and after 176 we got an additonal >>> error. >>> Afterwards we export the last 4 without a problem. >>> >>> So for us it seems that we loose during the processing the >>> references of >>> some of out products. The corrupt products hat the persistent >>> state 3 >>> (Commited) and after the change state 4 (Modified). The persistent >>> state >>> seems for us okay. >>> >>> Our Environment: >>> Windows XP >>> Oracle >>> Cayenne 1.2 >>> Jboss >>> Jdk 1.5.0.5 >>> >>> thanks >>> >>> florian >>> >>> >> >> >> >> > > > >