I took a very quick peek... looks like Mark is right, there are some
non-thread-safe practices going on there with both "conn" and
"connLastUsed".  Prob also want another check inside the sync block so
multiple threads don't pile up at that sync block and all open a new
connection in turn (or just put the check inside the sync block).

Is a finalizer really needed?  If so, hopefully the connection is
resistant to close() being called on it more than once?

-Yonik


On Tue, Nov 18, 2008 at 11:27 AM, Noble Paul നോബിള്‍ नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> it is not . conn is protected throughout
>
> On Tue, Nov 18, 2008 at 9:48 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
>> But if your going to sync a variable, you can't read/write it outside of
>> proper synchronization. Maybe I am just not following the code...
>>
>> Noble Paul ??????? ?????? wrote:
>>>
>>> one JdbcDataSource has only one connection the connection object/the
>>> connLastUsed etc needs to be protected.
>>>
>>>
>>>
>>> On Tue, Nov 18, 2008 at 9:24 PM, Mark Miller <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>>
>>>> JdbcDataSource looks like it has a little funkiness going on. Why is
>>>> there a
>>>> synchronize block there? Can multiple threads call getConnection
>>>> concurrently? If they can, this is not thread safe anyway. If they can't,
>>>> why is factory.call (or is it the close?) being protected with a sync?
>>>>
>>>> private Connection getConnection() throws Exception {
>>>>  long currTime = System.currentTimeMillis();
>>>>  if (currTime - connLastUsed > CONN_TIME_OUT) {
>>>>    synchronized (this) {
>>>>      Connection tmpConn = factory.call();
>>>>      close();
>>>>      connLastUsed = System.currentTimeMillis();
>>>>      return conn = tmpConn;
>>>>    }
>>>>
>>>>  } else {
>>>>    connLastUsed = currTime;
>>>>    return conn;
>>>>  }
>>>>  }
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> --
> --Noble Paul
>

Reply via email to