> Attached you find a logfile of the new thread test example.
> Two threads first put 10 times a large file into slide en then retrieve
> thier 10 entries.
> I also modified AbstractStore.enlist to sleep for 10 seconds (20
> retries).
>
> As you can see thread 2 can enlist the store and thread 1 gives a
> warning:
> Enlist failure: Resource manager
> slidestore.reference.JDBCDescriptorsStore@2a0f6c Error code XAER_OUTSIDE
> in Transaction 4 xid Thread-1-1004656777197-4- in thread Thread-1
>
> Everything normal so far, thread 2 continues to do its business, after
> the put thread2 starts getting the content from the database with a
> rollback after each operation.
>
> What I don't understand is why you get these errors:
> 02 Nov 2001 00:19:57 - org.apache.slide.transaction.SlideTransaction -
> WARNING - Enlist failure: Resource manager
> slidestore.reference.JDBCDescriptorsStore@2a0f6c Error code XAER_NOTA in
> Transaction 4 xid Thread-1-1004656777197-4- in thread Thread-1
>
> Thread 1 is still in the retry loop of the first enlist but doesn't get
> the store even when thread 2 is complete en the store is free.
>
> structurestore: slidestore.reference.JDBCDescriptorsStore
> contentstore: slidestore.oracle.OracleContentStore
> database + test program on single cpu windows machine
>
> Any idea why thread 1 doesn't get the store until after the exception ?
I fixed something, but I have a problem with the example, as I get:
java.io.IOException: Too many bytes read
at
slidestore.file.FileContentStoreNoVersioning.createRevisionContent(FileConte
ntStoreNoVersioning.java:280)
at
org.apache.slide.store.AbstractStore.createRevisionContent(AbstractStore.jav
a:1205)
at
org.apache.slide.store.StandardStore.createRevisionContent(StandardStore.jav
a:654)
at org.apache.slide.content.ContentImpl.create(ContentImpl.java:484)
at multithread.TestThread.run(TestThread.java:146)
at java.lang.Thread.run(Thread.java:484)
To fix it, I replace line 142 of TestThread with
revisionDescriptor = new NodeRevisionDescriptor(-1);
How can it work for you ?
The NOTA problem should be fixed.
The OUTSIDE problems, leading ultimately to the enlist failure are "normal",
and caused by the fact that the enlist retry is very lame. There really
should be a queue for this, as what happens is that your first thread will
just hang on to the store forever, since the amount of time during which the
store is not enlisted is just an instant (during which the other thread is
sleeping before trying to reenlist). Having RMs which would allow
parallelism would help a lot in that situation.
Remy
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
