lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fuad Efendi (JIRA)" <>
Subject [jira] [Commented] (SOLR-2233) DataImportHandler - JdbcDataSource is not thread safe
Date Tue, 31 May 2011 20:40:47 GMT


Fuad Efendi commented on SOLR-2233:

Existing implementation uses single Connection during 10 seconds time interval, and even shares
this object with other threads (if you try multithreaded)

So that problem becomes environment & vendor specific: to open new connection to Oracle
10g, for instance, we need to authenticate, and in "dedicated server" it might take a long,
plus "dedicated" resources for each connection, - server can get overloaded. MySQL, fro another
side, does not closes connection internally (even if you call conn.close() in your code);
connection will be simply returned to a pool of connection objects. And what if something
goes wrong... (what if MySQL or Oracle internals need additional time for "closing", "opening",
...) - we might even get problems like "too many connections". Modern apps don't see that
because they use manageable connection pooling instead of close-open...

I need to verify this patch; it was quick solution to make "threads=..." attribute working,
and it currently works in production system (MS-SQL).

> DataImportHandler - JdbcDataSource is not thread safe
> -----------------------------------------------------
>                 Key: SOLR-2233
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: contrib - DataImportHandler
>    Affects Versions: 1.5
>            Reporter: Fuad Efendi
>         Attachments: FE-patch.txt, SOLR-2233-JdbcDataSource.patch, SOLR-2233-JdbcDataSource.patch
> Whenever Thread A spends more than 10 seconds on a Connection (by retrieving records
in a batch), Thread B will close connection.
> Related exceptions happen when we use "threads=" attribute for entity; usually exception
stack contains message "connection already closed"
> It shouldn't happen with some JNDI data source, where Connection.close() simply returns
Connection to a pool of available connections, but we might get different errors.

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message