>- ***** Added support for verify.conn.sql property in your db conn
>def file. PoolConnDefinition will use this SQL statement to test
>whether a connection is still valid. If you're using oracle, you
>could add "verify.conn.sql=select 1 from dual". If you're using
>mssql, you could add "verify.conn.sql=select @@identity". This is
>most useful when exceptions are thrown as before, the pooler dropped
>the connection because it couldn't tell whether the connection was
>corrupt or not. If you encounter many SQL exceptions, this can
>greatly improve performance as assuming you just wrote bad SQL, it
>won't open/close multiple connections.
I'm a little confused. What exactly are those 'select 1 from dual'
or 'select @@identity' statements supposed to do?
Also, what's the current state of the Schema caching problems? I
made a quick-fix to it that I commited last week, but was told that
it was going to be re-written so that the conndef cached the Schema
instead.
I do think the latter idea is the better one, compared to my quick
fix. Has this been done yet?
On a different note, has anybody put any thought into a testing
platform for Town? I've become very weary about updating Town since
subtle changes that introduced equally subtle bugs have brought me to
my knees before. It would be nice if we had an organized way of
doing testing. One of the problems I've noticed is that everyone on
this list seems to be using Town for something a little bit
different, and the problems that one person applies to the code can
expose a bug that someone else's problems do NOT expose. For
example, as far as I know, only David and use the ORMapMaker, and as
far as I know, almost nobody uses Transactions yet.
Any ideas about this?
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
