Hi Jon,
> Is this a bug or the intended behavior? I assume a work around would
be to
> have Child be a proxiable object and remove the Collection proxy from
> Parent to Child, but I would rather not if I didn't have to.
Much thanks for the detailed description of your problem, this sounds
like a bug.
I remember that a similar problem was fixed for 1.0.4. Please try (if
possible) latest from CVS. Get OJB_1_0_RELEASE branch (should be
stable), trunk is instable 1.x. Between 1.0.3 and now several minor
fixes (related to odmg implementation) have been checked in.
If this doesn't solve your problem or you can't use the CVS version,
please make a bug report in jira including the metadata mapping of your
test case and pseudo code of your test (or the test itself if possible),
so that it's possible to setup an test case in OJB test-suite to
reproduce your problem.
regards,
Armin
[EMAIL PROTECTED] wrote:
Hello OJB gurus:
I'm having a repeatable problem with ODMG Transaction locking and unwanted
database insertions when I use proxy collections.
Here is a description of my environment:
[1] OJB 1.0.3
[2] implicitLocking=false in my OJB.properties
[3] I have an object of type Parent with a Collection of objects of type
Child. The Collection is via an indirection-table. Neither Parent nor
Child is a proxiable object (meaning that in the <class-descriptor>
elements for both Parent and Child, the "proxy" attribute is NOT
specified).
[4] The Parent collection of Child objects IS proxied via a Collection
proxy. This means that the "children" <collection-descriptor>'s "proxy"
attribute is set to true.
Here is what happens in pseudo code in run time:
[1] Opening persistent state: A given Parent object instance, parentA, has
one Child instance, ChildA, in it's Collection of children.
[2] A new ODMG Transaction is begun and parentA is retrieved from the
database. At this point, the Collection of Child objects (just childA) has
not yet been materialized.
[3] parentA is WRITE locked to the current transaction.
[4] A new child, childB, is created and WRITE locked to the transaction.
[5] childB is added to the Collection of parentA's children via
parentA.getChildren().add( childB ). I assume at this point the actual
Collection of children was materialized by the proxy during the call to
the getChildren() method.
[6] The transaction is committed and an SQLException occurs when the Child
primary key constraint is violated because OJB tries to re-insert childA
into the database. The Exception also occurs even if I WRITE lock childA
to the current transaction too before step 5. However, the exception does
NOT occur if I set the "proxy" attribute in Parent's children
<collection-descriptor> to false.
This leads me to believe that there is some state check when an object is
locked to a Transaction that is missing the existence of the proxied
collection of Children. When the proxied collection of Children is
materialized during the transaction, OJB incorrectly assumes that the
materialized childA also needs to be written to the database.
Is this a bug or the intended behavior? I assume a work around would be to
have Child be a proxiable object and remove the Collection proxy from
Parent to Child, but I would rather not if I didn't have to.
Thanks for the help,
Jon French
Programmer
ECOS Development Team
[EMAIL PROTECTED]
970-226-9290
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
