Armin,
Yes, it is mostly the same objects. It is reproducible at one of
our customer's installation and for now we have a workaround by
updating one object at a time in separate transactions. We can live with
this workaround for now because it is not a frequent operation and also
not very time critical. I have to simulate the same environment
here to reproduce it.
Pseudo code:
Get a OJB instance
Open Database connection READ_WRITE
Open Transaction odmg.newTransaction()
Begin Transaction
Retrieve all objects of class A by PB QueryByCriteria
CRITERIA_SELECT_ALL
For each object retrieved
do
Write-Lock each object for update Transaction.UPGRADE
Change value of attribute X
done
Commit Transaction
Close Database
I can not see the problem when the number of objects of class A
is small. Currently the problem is seen when the number objects is ~250.
For some objects, spy.log doesn't show the UPDATE sql statements.
Thanks for your help.
Regards
Ashish
Armin Waibel wrote:
Ashish Rangole wrote:
Armin,
batch mode = false in my configuration.
Really strange, never perceived such a behavior in OJB. Is it
reproduceable, did you lost always the same objects?
Could you send me a test or some pseudo code describing the problem?
regards,
Armin
Thanks
Ashish
Armin Waibel wrote:
Ashish Rangole wrote:
Is the field type the same for all modified classes? Maybe OJB has
problems to detect the changed field. You could try to change the
object state by yourself using OJB's odmg extensions via
TransactionExt#markDirty.
http://db.apache.org/ojb/docu/guides/odmg-guide.html#OJB+Extensions+of+ODMG
(this link is for >=1.0.3 but #markDirty exists in 1.0.1 too - AFAIK)
Yes the field is same for all modified objects which are of same
class.
From your suggestion above I get the impression that this is a known
bug in version 1.0.1. Please confirm. I wonder why does it behave
correctly for some of the objects in the transaction, then does not
for
some other. For eg if there are 200 objects retrieved and write locked
in the transaction, it will correctly persist the changes in ,say,
first 120, then miss the next 10 objects, then correctly persist the
remaining.
This is not a known bug, but I can't rule out that your problem is a
bug in 1.0.1.
Is the batch mode enabled (batch-mode="true" in
jdbc-connection-descriptor)? If yes, did you run the test with
disabled batch-mode? Do you get the same result with 1.0.4rc from CVS
(OJB_1_0_RELEASE branch)?
regards,
Armin
Thanks a lot for your time and help.
Ashish
---------------------------------------------------------------------
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]
--
--------------------------------------------------
Ashish Rangole
Vexcel Corporation - Image Information Engineering
1690 38th Street, Boulder CO 80301, USA
phone: 303-583-0286 fax: 303-583-0246
Vexcel's home page: http://www.vexcel.com
--------------------------------------------------
"What hobbyist can put 3-man years into programming, finding all bugs,
documenting his product and distribute for free?"
-- Bill Gates, An Open Letter to Hobbyists, 1976
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
