GeoTools

Unbounded prepared statement pooling can bring Oracle to its knees

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.6-RC1
  • Fix Version/s: 2.6.1
  • Component/s: jdbc
  • Labels:
    None

Description

See description in the GeoServer issue

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. GEOS-3727 Unbounded prepared statement pooling can bring Oracle to its knees

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Andrea Aime made changes -
Field Original Value New Value
Link This issue is depended upon by GEOS-3727 [ GEOS-3727 ]
Hide
Permalink
Andrea Aime added a comment -
Hi Christian, hi Justin,
I would like to squash this one swiftly, as it's really just a matter of exposing one parameter.

Just not sure how to expose it. As a Oracle specific param? Or we expose it for Postgis and H2 as well?
I guess we could declare the parameter in the general JDBCDataStoreFactory, and handle it in createDataSource(Map params, SQLDialect dialect), but let the subclasses decide if expose it or not?
Or else, have an overridable exposeMaxPreparedStatements() method that returns false by default, but the subclasses can override it and return true if they want to expose the parameter?
Show
Andrea Aime added a comment - Hi Christian, hi Justin, I would like to squash this one swiftly, as it's really just a matter of exposing one parameter. Just not sure how to expose it. As a Oracle specific param? Or we expose it for Postgis and H2 as well? I guess we could declare the parameter in the general JDBCDataStoreFactory, and handle it in createDataSource(Map params, SQLDialect dialect), but let the subclasses decide if expose it or not? Or else, have an overridable exposeMaxPreparedStatements() method that returns false by default, but the subclasses can override it and return true if they want to expose the parameter?
Hide
Permalink
Christian Mueller added a comment -
Andrea, as you like, for the moment I want to ignore this parameter, being not sure if I will need it in the future (I think not, but who knows ?)
Show
Christian Mueller added a comment - Andrea, as you like, for the moment I want to ignore this parameter, being not sure if I will need it in the future (I think not, but who knows ?)
Hide
Permalink
Justin Deoliveira added a comment -
No strong opinion either i guess. if i had to choose I would say just add the parameter in the base class and as you say have the subclasses explicitly expose it if needed.
Show
Justin Deoliveira added a comment - No strong opinion either i guess. if i had to choose I would say just add the parameter in the base class and as you say have the subclasses explicitly expose it if needed.
Hide
Permalink
Andrea Aime added a comment -
Fixed on 2.6.x and trunk
Show
Andrea Aime added a comment - Fixed on 2.6.x and trunk
Andrea Aime made changes -
Resolution Fixed [ 1 ]
Status Open [ 1 ] Closed [ 6 ]
Jody Garnett made changes -
Component/s jdbc [ 12180 ]
Component/s data jdbc-ng [ 13503 ]

People

  • Assignee:
    Andrea Aime
    Reporter:
    Andrea Aime
Vote (1)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: