we inherited our existing defaults which surely ignored this param I guess,
nothing more
Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau | Blog
http://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
LinkedIn https://www.linkedin.com/in/rmannibucau |
It seems maxWaitTime JDBC pool parameter solves basically the deadlocking.
You get exceptions, but the system doesn't hang.
One question how come the maxWaitTime parameter is set to endless. As the
default value in Tomcat is 30s. Is there a special reason for this.
Thanks again.
BR
Matej
Hi Jean-Louis, Mark.
The two queries are executed with default parameters in two different
methods. Connection on the database are adjusted accordingly.
We will now try playing with Hibernate, JPA, an other settings. To force
hibernate use only one connection. But I think only changing to
Additional information ...
1. A transaction unit of work is always executed in the same connection,
otherwise I don't see how it can work.
2. Are a/ and b/ executed in the same singleton method?
3. If yes, what the transaction attribute? default value?
4. A finder/query is not required per the
you might also need to look how many connections your db allows.
It doesn’t help if your Java connection pool allows 200 parallel connections
when your Oracle only accepts 50 concurrent connections…
LieGrue,
strub
Am 13.06.2015 um 08:43 schrieb Jean-Louis Monteiro jlmonte...@tomitribe.com:
Hmm, if there is a network issue then the connection should actually get
closed, right?
So the lock gets cleaned and you will see an Exception in your app.
Sounds really like a weird issue and I did not yet see this on any system yet.
The more important it is to get behind the real reason why
Le 11 juin 2015 09:49, Mark Struberg strub...@yahoo.de a écrit :
Hmm, if there is a network issue then the connection should actually get
closed, right?
Or not depends the setup but network but maybe not the right word. A
proxy/firewall can hold it for weeks even if behind there is nore any
This might be useless, but if you have nothing else to try, you can try
using the ip address instead of machine name in the jdbc url.
On Jun 11, 2015 12:51, Romain Manni-Bucau rmannibu...@gmail.com wrote:
Le 11 juin 2015 09:49, Mark Struberg strub...@yahoo.de a écrit :
Hmm, if there is a
No, proxies have a rather short and defensive socket retention time. Otherwise
they would too quickly become stuck and run out ot sockets…
LieGrue,
strub
Am 11.06.2015 um 18:51 schrieb Romain Manni-Bucau rmannibu...@gmail.com:
Le 11 juin 2015 09:49, Mark Struberg strub...@yahoo.de a écrit :
Was not a question Mark :p. Proxies doesnt always mean httpd or ngnix - and
here starts the issues.
Also remember having some very bad experience with oracle db when client
was not handling the timeout itself which is the case most of the time
AFAIK. Hold a connection (dead) for half a day or
Thank you all for help.
I think we have finally found something today. We simulated with a one
connection JDBC pool, and were able to generate a similar situation.
What we have found is that JPA can indeed use more then one connection per
transaction/session.
I an singletion if we run
well before playing with config the idea is to know what happened, is the
network quality the cause for instance?
Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau | Blog
http://rmannibucau.wordpress.com | Github https://github.com/rmannibucau |
LinkedIn
Thank you for help!
BRM
2015-06-10 20:21 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
2015-06-10 11:17 GMT-07:00 Matej gma...@gmail.com:
Hi.
Maybe what i forgot to tell is that when looking at the database we see
many connections like that:
IDLE IN TRANSACTION, mayn (ALL)
Hi Matej
looks like a database issue for me (stateless pool is waiting for the
stateless trying to get the db connection to be released), hasnt the DB
connection be lost or something like that?
Romain Manni-Bucau
@rmannibucau https://twitter.com/rmannibucau | Blog
On Wed, Jun 10, 2015 at 1:18 PM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:
Hi Matej
looks like a database issue for me (stateless pool is waiting for the
stateless trying to get the db connection to be released), hasnt the DB
connection be lost or something like that?
what is the
2015-06-10 10:59 GMT-07:00 Matej gma...@gmail.com:
Hi Romain.
We lookef for DB locks, but it's only SELECT and INSERT statements, which
should not cause locking on postgresql. And we also looked for locks using
postgresql debuging, analytics. So we suspected the network and the JDBC
driver,
Hi Romain.
We lookef for DB locks, but it's only SELECT and INSERT statements, which
should not cause locking on postgresql. And we also looked for locks using
postgresql debuging, analytics. So we suspected the network and the JDBC
driver, we did some TCP stack tuning, but also no major change.
2015-06-10 11:17 GMT-07:00 Matej gma...@gmail.com:
Hi.
Maybe what i forgot to tell is that when looking at the database we see
many connections like that:
IDLE IN TRANSACTION, mayn (ALL) transaction that are long running, waiting
for commit statemet which somehow doesn't happen.
And the
18 matches
Mail list logo
