db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert S. Sfeir" <rob...@codepuccino.com>
Subject Re: Lock Failure on Postgresql
Date Tue, 22 Jun 2004 12:39:15 GMT
Humm...

Martin, I can reproduce this on my machine consistently with Postgresql
7.4.3.  I'm running OS X on a 1.5 Ghz powerbook with 1 gig of RAM.  When
running the unit tests that's the only thing running on my machine.

I've just downloaded the demo of jprofiler, which works on the Mac, and will
do automatic deadlock detection.

I have a funny feeling about this issue, and though it might well be the
test case, I want to find out for sure.  My hunch is there is a thread
locking issue, however subtle.

I have a class to attend, a class to give, and a monthly director's meeting
to attend today, so I might not get to this until tonight or tomorrow AM...
So forgive me for the delay.  If we must, release as is, and if there is a
threading issue, we fix and release 1.0.1 or something.

After that I'll see how much jprofiler will let me run for, and I'll run
some profiling on OJB just to see where we can improve performance in
general and see if we have any memory leaks etc...

R


On 6/21/04 9:06 PM, "Martin Kalén" <martin.kalen@curalia.se> wrote:

> Robert S. Sfeir wrote:
> 
>> Looks like postgres is exhibiting the same symptoms as Oracle.  It looks
>> like the test thinks someone else modified an object and can't get a lock
>> and the test fails, either that or there is serious thread locking going on
>> here.
>> 
>> org.apache.ojb.odmg.LockingMultithreadedTest$LockObjectRef@2fcbd8 for WRITE
>> [DEFAULT] WARN: ### thread 3 waits 71 times. Maximal attempts are 100
> 
> I have seen this as non-deterministic (because of not 100% reproducable)
> behaviour
> on Oracle9i and had a look at the LockingMultithreadedTest for ODMG.
> 
> It is a regression test with an inherit timing issue in the assertion;
> a bit shaky for a JUnit test if you ask me. ;-)
> 
> If your machine has a lot to think about while running the JUnit tests
> (or your remote RDBMS server is very busy) -- LockingMultithreadedTest will
> fail.
> 
> 
> You can change the "int threads = 6" parameter to "int threads = 60" to get
> an almost certain 100% reproducable test-case failure...
> 
> 
> IMO it's not good enough to just add more discrete steps to the "maxAttemps"
> parameter that cause the test to fail. Another machine running the tests
> will (according to Murphy's law) be busy enough to make it fail anyway.
> 
> Same goes for converting discrete int step counting to long/timestamps and
> checking delta times spent trying to aquire locks. This will still lead to
> a regression test with a race-condition.
> 
> 
> I think someone should take a look at refactoring LockingMultithreadedTest
> a bit so that it uses a more deterministic rule for determining test failure.
> 
> The way it is now, people might think ODMG is shaky when it is in fact only
> the test case.
> 
> Regards,
>   Martin




---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message