Yes, you're probably right that we should default to
blocking. That's easy enough to fix.
Aaron
On Fri, 6 Oct 2000, Daniel Schulze wrote:
> Aaron,
>
> while running my stress test (will be in cvs (jbosstest) until the next
> hour) on jBoss I ve noticed the following:
>
> scenario:
> - n threads use m beans (every thread his own beans = n*m beans in
> the server during the test)
> - per test loop the client calls a getter of every bean and then the
> setter for the same property
>
> problem:
> If there are more client threads running then the pool maxSize, I get
> ugly exceptions that indicate a rollback. However, when I set the
> blocking flag in the pool settings to true (default = false) all
> runs fine.
>
> what to do:
> I read in the pools doc, that if blocking is set to false and no free
> connection is available, the pool returns null. I guess this case is
> not considered in the code that uses this pool...
>
> As first solution would be good to set blocking true by default. When I
> find the time I maybe will have a look at it, but if one of you is
> familiar with the code, I would appreciate if one of you could fix that.
>
> bye Daniel
>
>
>
> -----8<--------------------------------------------------------
> client side exceptions:
>
> java.lang.reflect.UndeclaredThrowableException:
> javax.transaction.RollbackException: Unable to commit,
> status=STATUS_ROLLEDBACK
>
>
> java.rmi.ServerException: Remote
> Exception occurred in server thread; nested exception is:
> javax.transaction.TransactionRolledbackException: Load failed; nested
>exception is:
> java.lang.NullPointerException; nested exception is:
> java.rmi.ServerException: Load failed; nested exception is:
>
>
>
