On Tue, 2 May 2006, Binod wrote:
> Joseph B. Ottinger wrote:
>
>> Refreshing the context: I'm writing an app that uses MDBs and JPA (and a
>> timer) to create lots and lots of data on a regular basis (it crawls a set
>> of pages and logs changes.)
>>
>> I set up the DB connection pool to have 64 connections maximum; however, I
>> find that I'm getting a max pool size used message an awful lot.
>
> And how many users you have?
Hrm, well... hard to say how many messages are being pumped through the
system at any given time. It can certainly skyrocket, so I can imagine
it's pretty high.
> 64 max-pool-size means that only a maximum of 64 threads can use pool
> simultaneously.
>
> Also, if one thread need more than one connection at the same time, then the
> sizing will be different.
> This can happen if there is a
> startTx-useConnection->suspendTx->startNewTx->useConnection->endNewTx->endTx
> kind of a scenario in an application.
Well, there are cases where a single MDB uses two DAOs, each of which has
its own EntityManager. Apart from that, I haven't set any transaction
attributes at all.
> In the first look, it look like you are having a sizing problem.
That's what I thought, too, except running under a situation where you
shouldn't have a ton of connections being created *also* fired off the
same connection count. Further, once I get the out-of-connections message,
the appserver never recovers -- a bigger problem, in my opinion.
> - Binod.
>
>>
>> Now, I'll gladly admit that I'm hammering the DB on update - a single web
>> page that changes can generate 300+ new entities (or updates to existing
>> entities) or more, actually. I haven't actually tested boundaries yet,
>> because the app's barely in smoke-testing stage.
>>
>> However, I'm not using *any* connections manually - everything's going
>> through JPA, so connection allocations should be fairly short-lived. Am I
>> seeing something incorrect in action?
>>
>> -----------------------------------------------------------------------
>> Joseph B. Ottinger http://enigmastation.com
>> Editor, http://www.TheServerSide.com joeo@enigmastation.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
-----------------------------------------------------------------------
Joseph B. Ottinger
http://enigmastation.com
Editor,
http://www.TheServerSide.com joeo@enigmastation.com