[
https://jira.jboss.org/jira/browse/JBAS-7788?page=com.atlassian.jira.plug...
]
Adrian Brock commented on JBAS-7788:
------------------------------------
If you want to start a discussion use the forums.
But I don't see how this behaviour can have anything to do with Seam
other than you are not detecting datasource errors, so you are not
destroying broken/stale connections.
There's certainly no comment on the Seam bug report from anyone
other than you that confirms there is any problem there.
check-valid-connection-sql or valid-connection-checker is one mechanism
as is background-validation to detect stale connections.
But there's also the exception-sorter-class-name
to decide if it is a fatal error AFTER an sql call is made
and it throws an SQLException.
SQLExceptions are not normally treated as fatal.
It's all explained in the docs, e.g.
http://community.jboss.org/wiki/ConfigJCACommon
http://community.jboss.org/wiki/JBossJCAPooling
Like I said above, if you want to discuss hardening your datasource pool
configuration use the forums. JIRA is not the place for help requests.
I'm only leaving this open, because we could implement a kind
of auto-reconnect for connections in auto-commit mode
so it is a valid feature request, but it is not your use case AFAIK.
<check-valid-connection-sql> done after a failure maybe?
--------------------------------------------------------
Key: JBAS-7788
URL:
https://jira.jboss.org/jira/browse/JBAS-7788
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: JCA service
Affects Versions: JBossAS-5.1.0.GA
Reporter: deanhiller
Assignee: Jesper Pedersen
Priority: Critical
related directly to this bug in seam
https://jira.jboss.org/jira/browse/JBSEAM-4528
I would prefer the <check-valid-connection-sql> be run AFTER any exceptions from
the jdbc api rather than before it. This would fix half the bug in the ticket referred to
above(at least with postgres' case)....
ie.
1. go get a wrapper connection(not from pool)
2. when you make a real jdbc call, go get the real connection from the pool
3. if that jdbc call fails with an exception, run the check-valid-connection-sql
4. If check-valid-connection-sql fails, go get another connection from pool(or create
one) and if fails, move to next
5. once all connections are exhausted, throw exception back to framework or whoever
called the jdbc call.
NOTE: This gives the performance benefit on sunny day we are never running the check
valid connection sql. It also solves half of the ticket above which tends to break
postgres/jboss/seam combination from working. I have to have check valid connection sql
or my seam app never recovers from a db outage but having that also causes all normal seam
pages that don't need the database to spin the browser into infinite redirect(ie. if I
hit login page it comes up in jboss/seam IF AND ONLY IF I don't have
check-valid-connection-sql set).
thanks,
Dean
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira