[jboss-jira] [JBoss JIRA] Commented: (JBAS-7788) <check-valid-connection-sql> done after a failure maybe?

deanhiller (JIRA) jira-events at lists.jboss.org
Mon Mar 8 10:30:59 EST 2010


    [ https://jira.jboss.org/jira/browse/JBAS-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12518711#action_12518711 ] 

deanhiller commented on JBAS-7788:
----------------------------------

What if you just did a read from the db like in oracle select sysdate from dual after a failure?  if that fails, then don't you know it was the connection that failed?  doesn't that allow you to never have to call the check-valid-sql stuff before the transaction starts to get rid of that performance penalty.  Also, I am not as worred about the performance as I am that this is breaking seam from working correctly.

If check-valid-sql failed, well, the whole transaction was bad and then we can check the next connections with check-valid-sql first because we know one connection was bad, the others may now be bad too as in the db being down.

my email dean at xsoftware.biz if you want to discuss more.

> <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

        



More information about the jboss-jira mailing list