Home » Eclipse Projects » EclipseLink » pool: 1 connection
pool: 1 connection [message #974736] |
Wed, 07 November 2012 09:31 |
Tom Eugelink Messages: 825 Registered: July 2009 |
Senior Member |
|
|
I'm using Eclipselink inside a Swing client, this means that connection pooling has a lesser performance advantage, however unnecessary connections have a big RDBMS license impact.
Is it possible to configure EL to only use one connection? I now have this setup:
lOptions.put(PersistenceUnitProperties.JOIN_EXISTING_TRANSACTION, "true"); // reads and write should go through the same connection, otherwise batchtransfer will have connection conflicts
lOptions.put(PersistenceUnitProperties.JDBC_SEQUENCE_CONNECTION_POOL , "true"); // this is deprecated, but the replacement CONNECTION_POOL_SEQUENCE does not work on 3.1.2-M1 // force sequences to use a separate pool, so rollback do not undo counter increments
lOptions.put(PersistenceUnitProperties.CONNECTION_POOL_INITIAL, "1"); // for the RDBMS licenses
lOptions.put(PersistenceUnitProperties.CONNECTION_POOL_MAX, "1"); // for the RDSBMS licenses
This results in two connections when I ask the RDBMS, I suspect one for data and one for the sequence?
If I set it up like this (replace JDBC_SEQUENCE_CONNECTION_POOL).
lOptions.put(PersistenceUnitProperties.JOIN_EXISTING_TRANSACTION, "true"); // reads and write should go through the same connection, otherwise batchtransfer will have connection conflicts
lOptions.put(PersistenceUnitProperties.CONNECTION_POOL_SEQUENCE , "true"); // force sequences to use a separate pool, so rollback do not undo counter increments
lOptions.put(PersistenceUnitProperties.CONNECTION_POOL_INITIAL, "1"); // for the RDBMS licenses
lOptions.put(PersistenceUnitProperties.CONNECTION_POOL_MAX, "1"); // for the RDSBMS licenses
There now only is one connection, but that scares me a bit, because not using the deprecated option should not change the behavior.
So:
1. Is there any way to see what a certain connection is intended for?
2. Is it possible to setup a pool with a single (or even 0) permanent connections, but still have the sequences done in a separate transaction (opening a separate connection if needed)?
Tom
|
|
| | |
Re: pool: 1 connection [message #982960 is a reply to message #974869] |
Tue, 13 November 2012 15:13 |
|
I would not use, JOIN_EXISTING_TRANSACTION, but instead use, EXCLUSIVE_CONNECTION_MODE="Always"
Do you want 1 connection, or 2 (1 for access, and 1 for sequence)?
In general this is a very bad idea as you will only be able to support a single thread, but I assume you know the limitations.
To use 0 connections you can try setting CONNECTION_POOL_INITIAL to 0 and CONNECTION_POOL_MIN to 0, but this will need to connect for every transaction, so will be very inefficient.
If you use JTA, then if you remove your sequencing options a the same connection will be used for sequencing (you will only use 1 connection).
If you want 2 connections, one for transactions, and one for sequencing then using the sequence connection pool of size 1 is correct.
James : Wiki : Book : Blog : Twitter
|
|
|
Re: pool: 1 connection [message #983346 is a reply to message #982960] |
Tue, 13 November 2012 21:40 |
Tom Eugelink Messages: 825 Registered: July 2009 |
Senior Member |
|
|
On 2012-11-13 16:13, James Sutherland wrote:
> I would not use, JOIN_EXISTING_TRANSACTION, but instead use, EXCLUSIVE_CONNECTION_MODE="Always"
I'll take a look at the exclusive_connection_mode, but the problem the join_existing_transaction solves is that I have some native SQL going on, dating back to the direct JDBC version, that does some explicit locking on tables. And that needs to happen within the same transaction.
> Do you want 1 connection, or 2 (1 for access, and 1 for sequence)?
Actually I want one pool, with one active connection as the basis, with the option to temporarily open more.
> In general this is a very bad idea as you will only be able to support a single thread, but I assume you know the limitations.
It is a matter of performance vs money. Do note that we're not talking about an application server, but individual fat Swing clients.
It uses a single thread to store the information anyhoew.
But it would not be a problem that it temporarily creates a additional connections, as long as they are closed again after use.
> To use 0 connections you can try setting CONNECTION_POOL_INITIAL to 0 and CONNECTION_POOL_MIN to 0, but this will need to connect for every transaction, so will be very inefficient.
Tried that, no good.
The reason I want this is because you can specify two pools (one for data one for sequences), but each pool keeps at least one connection open.
If I do not use a separate pool, then a rollback also rollback the increments on the sequence table. These should never rollback.
It would be much better if the sequences would use the same pool, but not the same connection/transaction.
There is no SEQUENCE_SEPARATE_CONNECTION setting, right?
> If you use JTA, then if you remove your sequencing options a the same connection will be used for sequencing (you will only use 1 connection).
I do not use JTA, but direct EM transactions.
> If you want 2 connections, one for transactions, and one for sequencing then using the sequence connection pool of size 1 is correct.
Yes, but it creates two pools, each with one connection.
I would like to see one pool, with one open connection and the possibility to temporarily open more.
Tom
|
|
| |
Re: pool: 1 connection [message #986489 is a reply to message #986233] |
Tue, 20 November 2012 15:56 |
|
You can use the same pool for both the read/write pool and for the sequence pool.
I don't think there is a persistence unit property for it (other than using a shared DataSource pool), but you can use a SessionCustomizer for it,
something like,
session.getSequencingControl().setConnectionPool(session.getDefaultConnectionPool());
It is not normally a good idea in a server environment, as you can deadlock getting a sequence if the pool is maxed out.
James : Wiki : Book : Blog : Twitter
|
|
| | |
Goto Forum:
Current Time: Thu Sep 19 05:20:15 GMT 2024
Powered by FUDForum. Page generated in 0.05050 seconds
|