for example try setting the timeout to 2 seconds and the wait in the bean at
4 seconds...
:), do you see it? if the timeout is in the bean then we don't register and
thus we never clean the tx, then with the current cache there are problems
in how you access that information in a isolated fashion, broken..
I'm on top of it, got the fix with the next generation of synchronization...
but it is 12:30 am and I need to get up at 5 to go to the INS and get my
permanent residency card... yep got to be in line at 6am otherwise "me no
get in, and me no get card at INS (US immigration FYI)"
I will try to commit tomorrow,
for those who didn't know already,
I am an alien
currently legal in the US mind you
marcf
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of marc
|fleury
|Sent: Sunday, July 01, 2001 11:39 PM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] new Threads.java (cache bug tests) is
|incomplete.
|
|
|Ok finishing the test of the cache, found interesting stuff...
|
|onto your mail
|1- turn of html
|2- see below
|
|Don't get annoyed with me, but your new threads test is incomplete:
|
|that's ok, I don't shoot the messenger, I do shoot the implementor
|
|
|
|- You need to also randomize on the bean's primary key. I say this because
|some of the cache bugs I encountered were as a result of one
|thread throwing
|a context back into the InstancePool(via a rollback or remove)
|while another
|thread(i.e. PassivationJob) had a reference to it and was using it. Also,
|with your test the way it stands, your entity calls will be serialized, so
|you have almost no chance of creating a race condition.
|
|yes, I realize that putting the pools put an order of magnitude of
|complexity on top of something that is already tremendously complex (the
|synchronization of calls). I have removed the pools (by simply not
|returning objects to them, they are still there from a code standpoint).
|
|I don't understand the second point, what do you mean the calls will be
|serialized? please explain,
|
|
|
|- You should test the state of your entity bean
|i.e.
|
|class EJBThreadsBean implement EntityBean {
|public void test(String shouldBe)
|{
| if (!shouldBe.equals(id)) { throw new RemoteException("state
|invalid"); }
|}
|}
|
|sure, that was with the pools stuff, again I removed that, much simpler now
|
|
|
|- You should test against option 'A', 'B', and 'C' since they are all
|totally different behaviour.
|
|yes that is a point, we should run the series of test with A, B and C
|configuration options, this is independent of the code.
|
|
|You could turn this around and say, "Bill, why don't you do it then?", then
|I'd happily say, "Sure!".
|
|well the pool stuff is gone so the test in there does stress the server, I
|already removed a bug in the current base which is that the synchronization
|interceptor was not checking for a rollbacked transaction in the
|beforeCompletion call and that caused the pools to barf.
|
|marcf
|
|
|
|Regards,
|
|Bill
|
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
