Thanks Armin. flush() fixes the problem. I just tried upgrading to
1.0.2, but that doesn't appear to fix the problem. I can live with the
flush() workaround until that is solved.
Thanks again, I appreciate your help.
Colin
Armin Waibel wrote:
Colin Kilburn wrote:
Hi Armin, thanks for the response.
I'm using OJB 1.0.1. I've never noticed the TransactionExt.flush()
method. Calling it does seem to fix the problem. I do have 2
questions, however:
1. the javadoc says flush() is very similar to
Transaction.checkpoint(). How do they differ?
flush() only writes the objects to DB, connection still remain.
checkpoint() write objects and commit the connection
both methods keep the locks.
and would it be preferable to call checkpoint() instead?
Nope, because after checkpoint no rollback is possible.
(calling checkpoint() seems to
work as well)
2. is calling flush() expensive?
Not really, compared with the write to the DB.
(I have a wrapper around all my lock() calls, would it be excessive
to call flush() after every lock(), even when it's not needed?
In this case I would expect an performance decrease. A performance
test case should shed some light on this.
In OJB 1.0.2 the odmg-api is completely refactored and many bugs are
fixed. I assume that your bi-directional problem will be solved in
this version (take care of new metadata settings and properties).
regards,
Armin
Colin
Armin Waibel wrote:
Hi Colin,
which version of OJB do you use?
Did you try to use TransactionExt.flush() calls to separate the calls
> beginTxn();
>
> B b = new B();
>
> a.setCurrentB(b);
>
> lock(b); // corresponds to an INSERT into B's table
((TransactionExt) tx).flush();
> lock(a); // corresponds to an UPDATE on A's table, with a FK
reference
> to the just-inserted B
>
> commitTxn();
regards,
Armin
Colin Kilburn wrote:
Hi All,
I'm currently having a problem with reordering of written objects
done by the org.apache.ojb.odmg.ObjectEnvelopeTable.reorder()
method. I have implicit locking off, and I always "lock" objects
in the order they would have to in order to maintain referrential
integrity. That is, I don't think I would have a problem if I
could disable "reordering" before committing a transaction. Is
there a way to disable reordering?
The following is an attempt to describe my situation:
I currently have a bi-directional relationship between two
objects. Say I have two classes A and B:
class A {
private B currentB;
}
class B {
private A a;
}
An A can have multiple B's, but it keeps a pointer to the current
B, which is updated every time a new B for that A is created.
This bi-directional relationship seems to cause problems for the
ObjectEnvelopeTable.reorder() method. I.e., when doing the
following (pseudocode):
beginTxn();
B b = new B();
a.setCurrentB(b);
lock(b); // corresponds to an INSERT into B's table
lock(a); // corresponds to an UPDATE on A's table, with a FK
reference to the just-inserted B
commitTxn();
What ends up happening is that the UPDATE is happening before the
INSERT, which fails because currentB's id is not yet defined. By
playing with the order that I lock those objects and others within
the transaction, I can sometimes get them to go in the right order,
but this is hokey. The problem resurfaces when tearing down my
unit tests, as the reordering at delete time can also get messed
up. The following thread describes a similar problem to mine.
http://www.mail-archive.com/[email protected]/msg05317.html
Anyway, I think if I could disable reordering, perhaps in the
OJB.properties or something, I would cease to have this problem.
The other obvious (but not really acceptable) solution would be to
do these writes in separate transactions, making reorder()'s
effects harmless.
Thanks in advance for any help,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
