|
Home > Archive > WebSphere Application Server > September 2006 > Behavior of the Container When The Database is Unavailable
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Behavior of the Container When The Database is Unavailable
|
|
|
| Hi there,
Hope someone can share with me how will the container behave when the below happens:
1) The container is able to provide the entity bean for the application
2) The application task is completed and entity bean ready to commit to the Database.
3) The Database have gone unavailable.
4) The container commit unsuccessfully, it is then trying to rollback the transaction.
My question is what will happen to that particular transaction and application? What I have encounterred is the requests keep coming to the Websphere App Server, and the container seem like can't release the resources and eventually use up all the resou
rces in the App Server.
Pls help. Thanks alot.
| |
| Ken Hygh 2006-09-25, 1:30 pm |
| ckar_joon@yahoo.com wrote:
> Hi there,
>
> Hope someone can share with me how will the container behave when the below happens:
>
> 1) The container is able to provide the entity bean for the application
> 2) The application task is completed and entity bean ready to commit to the Database.
> 3) The Database have gone unavailable.
> 4) The container commit unsuccessfully, it is then trying to rollback the transaction.
>
> My question is what will happen to that particular transaction and application? What I have encounterred is the requests keep coming to the Websphere App Server, and the container seem like can't release the resources and eventually use up all the res
ources in the App Server.
>
> Pls help. Thanks alot.
The transaction will be rolled back, and an Exception will be thrown to
your application. You are then expected to handle it appropriately.
If your database goes unresponsive, then requests to use it within the
container will time out. However, if enough requests come in before
timeouts occur, then every thread waiting for the timeout will block. If
you have configured an equal number of threads in the container to the
number of connections in your connection pool, then the container will
appear to be unresponsive.
Best practice is to always configure fewer connections in the connection
pool than number of threads in the J2EE container that'll be using it.
Ken
|
|
|
|
|