[
https://issues.apache.org/jira/browse/SOLR-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041811#comment-13041811
]
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: https://issues.apache.org/jira/browse/SOLR-2233
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]