Mailing-List: contact cayenne-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cayenne-user@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of poldwusmokow@gmail.com
 designates 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type;
        b=Mo+k2UnK1bk8tNLQix5tkAKUPce2MqgwOrtOCgBP9CLGWOYjiNsB1Y9nXCi6D/G7CZDWiSvDwVu15dfZMn4JxJ5ceDky4xiqz60YpVqdQKm4UQW05fy/YVKE66ZvTEnK8MJJmZdsXX3DOcKP/726PxPXWpC66dM9B2N2GA9TqIw=
Message-ID: <1988d1640607032105g37825e8amd40bbb29bc8e6766@mail.gmail.com>
Date: Tue, 4 Jul 2006 14:05:10 +1000
From: "Marcin Skladaniec" <poldwusmokow@gmail.com>
To: cayenne-user@incubator.apache.org
Subject: concurrent modification exception (cayenne 3.0 branch,
 remote persistence)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_4924_18197902.1151985910117"

------=_Part_4924_18197902.1151985910117
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi everyone !

I have this mysterious problem: I'm committing a dozen different records in
one go (payments, payer, invoices, accounts etc). Right after the commit
(when state of some records changes to PersistentState.COMMITED) I create
and commit some extra records and than I commit those new records again
(separate context, all happening on server). All nice. All records saved. No
problem. Than right after after the persistent state is changed I get
"concurrent modification exception", and context on client is returning this
exception, trying to revert changes (but there is nothing in the context)
etc. If I don't restart the application, just create a new context and
repeat the whole process again it works. I though "strange" and I started to
debug the problem.
First I wrote a piece of code which steps thru all records in the context
and prints their attributes and relationships just before the commit to see
what is actually commited, and ... everything works without throwing any
exception.
Than I looked at cayenne code to find what can be causing the concurrent
modification exception. My suspect is call to clear() in graphCommited() in
ObjectContextStateLog, but why ? What I'm I doing wrong so the first time it
fails only for the first time, and only if some objects are not faulted ? I
don't know which objects are actually causing this problem, because if I try
to debug them on client I have to fault them, and this is preventing
exception, and on server I have no real hook to see what is going to be
committed.

Marcin

PS. I'm subscribed to the list, but I had to sent this email from different
account.

-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001

------=_Part_4924_18197902.1151985910117--