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 ?
Dirk
Remy Maucherat wrote:
>
> > Your multi thread test works now fine with me, no errors.
> > The only problem I have now have is that the retry mechanism in
> > AbstractStore.enlist doesn't seem to work.
>
> I didn't see any way around. If the store refuses to be enlisted because
> it's busy, then the retry is used. So it doesn't work ?
>
> > This could be related with bug 3935.
>
> Maybe.
>
> > I'm going to synchronize all the database connection operations like I
> > mentioned a few weeks ago and use a temp file in
> > retrieveRevisionContent, that should help with your original oracle
> > error. I didn't get the error but I'll try some different thread
> > configurations.
> >
> > Using an XA jdbc driver might help but using a connectionpool or store
> > pool will improve performance and solves all these database transaction
> > problems because then we can always enlist the store even for read-only
> > operations or at least have a pool with read-only stores.
>
> It would definitely be a lot better, since 1 connection <-> 1 transaction,
> so the store would be able to scale a lot better.
>
> Remy
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
test.log
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
