Comments (2)
Comment author: Arie van Wijngaarden <[email protected]>
While working with the JDBC service specification, I found the following issues:
Section 125.3.2:
- For creating a DataSource and variants it is possible to pass the URL using the property JDBC_URL. However, it is also possible to pass separate values for host, port, protocol, database, etc. This is ambiguous, or a statement must be made what takes precedence.
- The pool parameters JDBC_INITIAL_POOL_SIZE, JDBC_MAX_IDLE_TIME, JDBC_MAX_POOL_SIZE, JDBC_MAX_STATEMENTS, JDBC_MIN_POOL_SIZE apply according to the specification to ConnectionPoolDataSource and XADataSource. However, according to the Java API those data sources do not implement connection pooling at all. They are designed to work with pool managers not provided by the implementation. For those data sources, the pool parameters have actually no use.
- Related to this: connection pooling is an important issue and given the previous remark it is probably the intention to allow service implementers to provide some means for connection pooling. I would suggest to include those parameters for normal DataSources as created with the createDataSource method.
- The parameters passed as properties could get more explanation. Examples: what do the properties JDBC_ROLE_NAME and JDBC_PROPERTY_CYCLE mean? What is the unit of time in which JDBC_MAX_IDLE_TIME should be given?
from design.
Comment author: Ivan Dubrov <[email protected]>
Let me add a few cents here. Here is discussion I initiated on osgi-dev mailing list a time ago: https://mail.osgi.org/pipermail/osgi-dev/2010-July/002568.html
Here is the excerpt of the post (with few edits):
- Should DataSource returned by DataSourceFactory#createDataSource return DataSource that pools connections or it should return DataSource that will provide "raw" connections (no pooling)?
I think it is crucial for client to know if DataSource returned from createDataSource implements pooling or not. So, there should be either way to force implementation to return DataSource with pooling (or throw an exception) or there should be way for the client to see if returned DataSource implements pooling at all.
The first case is obviously the preferred for client (so they don't need to bring their own pool implementation if they don't want to), but forces the JDBC provider to brings its own.
The second variant is less useful, because it leaves two options: implement client to be flexible about pooling (use its own pool if required), which complicates code or use it's own pool unconditionally (which makes pooling aspect of this specification useless).
- What does DataSourceFactory#JDBC_INITIAL_POOL_SIZE and
DataSourceFactory#MAX_POOL_SIZE mean? In my understanding, they only
make sense if applied to the createDataSource in case it uses connections from pool. Those properties do not make sense for ConnectionPoolDataSource, since ConnectionPoolDataSource should always
create new physical connections (see PooledConnection).
from design.
Related Issues (20)
- Ordering issue with RFC-217 "osgi.jaxrs.filter.base" filters HOT 2
- rfc-217 should clarify how ApplicationPath annotation can affect the base path HOT 1
- RFC-217 support for Feature, DynamicFeature, ContextResolver and other providers HOT 3
- RFC-221 Transaction control: Release resources managed by JDBCConnectionProvider HOT 4
- Typos in RFC 221 Transaction Control - Drafs HOT 1
- RFC-229 MQTT Wildcard topics HOT 2
- [Converter] Conversion of Collections HOT 2
- R7 Core draft 2017-3, 10.8.4.3 (Capability and Requirement version params) HOT 2
- Configurer specification - partial configurations and merging (R8+) HOT 2
- Feature: support Optional<T> for DS service reference type HOT 3
- [RFC 216/ PushStream] Inconsistency between JavaDoc/Spec Section 706.7.14.6 and the reference implementation HOT 1
- [RFC 216/ PushStream] Inconsistent time unit of PushbackPolicyOption.getPolicy() between JavaDoc and implementation HOT 4
- Component "outjection" for declarative services. HOT 1
- rfc-241 (Feature) - json structure and comment HOT 4
- Offer BundleContext#registerService without HashTable HOT 4
- [JPA Service] allow a JPA Service to use the (non-)jta-data-source attribute instead of the javax.persistence.jdbc.driver property HOT 1
- DS 1.4 Component Property Types: Allow meta annotations or static fields for generating constant component properties HOT 3
- DS 1.4 Component Property Type Annotations: Allow elements which only optionally create component properties HOT 1
- DS: Allow a condition towards a framework property HOT 3
- DS: Allow conditions for a class being available to the classloader HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from design.