Re: [net] Version 3.7
On 21 August 2018 at 18:10, eddma01 wrote: > Is there a date when commons-net 3.7 is estimated to be released? Not as yet. > Need to move away from vulnerability in 3.6. > Which vulnerability? > > -- > Sent from: > http://apache-commons.680414.n4.nabble.com/Commons-User-f735979.html > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [net] Version 3.7
Is there a date when commons-net 3.7 is estimated to be released? Need to move away from vulnerability in 3.6. -- Sent from: http://apache-commons.680414.n4.nabble.com/Commons-User-f735979.html - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [dbcp] Unnecessary ROLLBACK's with BasicDataSource
Hello, Can you proof that this puts additional pressure on the database? It does make some uneccessary round-trips but the database will just ignore the rollbacks when there are no open changes/transactions IMHO. Did you see somewhere on the database otherwise? Using rolllback unconditionally to reset the state of transactions is easier and more reliable than actually trying to keep track. If it does indeed affect the database it would be a bit more work to come up with another solution. Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net Von: Andrey Shcheglov Gesendet: Dienstag, August 21, 2018 5:01 PM An: user@commons.apache.org Betreff: [dbcp] Unnecessary ROLLBACK's with BasicDataSource Hello, If BasicDataSource (version 1.4, as I'm limited to Java 1.6) is configured with defaultAutoCommit=false, then two extra ROLLBACK's are executed, one when a database connection is taken from the pool, and another one when returning a connection to the pool. The corresponding stack traces are (/Oracle Thin/'s T4CConnection example): > T4CConnection(PhysicalConnection).rollback() line: 1950 > PoolableConnection(DelegatingConnection).rollback() line: 368 > PoolableConnectionFactory.passivateObject(Object) line: 685 > BasicDataSource.validateConnectionFactory(PoolableConnectionFactory) > line: 1559 > BasicDataSource.createPoolableConnectionFactory(ConnectionFactory, > KeyedObjectPoolFactory, AbandonedConfig) line: 1545 > BasicDataSource.createDataSource() line: 1388 > BasicDataSource.getConnection() line: 1044 and > T4CConnection(PhysicalConnection).rollback() line: 1950 > PoolableConnection(DelegatingConnection).rollback() line: 368 > PoolableConnectionFactory.passivateObject(Object) line: 685 > GenericObjectPool.addObjectToPool(Object, boolean) line: 1379 > GenericObjectPool.returnObject(Object) line: 1342 > PoolableConnection.close() line: 90 > PoolingDataSource$PoolGuardConnectionWrapper.close() line: 191 Thus, each successful database transaction is a sequence of: 1. ROLLBACK (connection taken from the pool) 2. do something with the database connection (application code) 3. COMMIT (application code) 4. ROLLBACK (connection closed) (instead of a single COMMIT), while each failed one is a sequence of 1. ROLLBACK (connection taken from the pool) 2. do something with the database connection (application code) 3. ROLLBACK (application code) 4. ROLLBACK (connection closed) (instead of a single ROLLBACK). This behaviour applies an additional pressure to the redo and undo subsystems (particularly, in /Oracle/ case, but the problem holds for any database accessed via /commons-dbcp/, e. g.: I observed the same issue with /MySQL/). *Question 1*: how can I get rid of these extra ROLLBACK's while still having my data source configured with defaultAutoCommit=false (i. e. without the need to manually call setAutoCommit(false) for each connection taken from the data source)? *Question 2* (I'm aware I may be barking up the wrong tree, but still): alternatively, how can I mitigate the issue from /Oracle/ side (i. e. without changing my code or replacing libraries)? Regards, Andrey. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[dbcp] Unnecessary ROLLBACK's with BasicDataSource
Hello, If BasicDataSource (version 1.4, as I'm limited to Java 1.6) is configured with defaultAutoCommit=false, then two extra ROLLBACK's are executed, one when a database connection is taken from the pool, and another one when returning a connection to the pool. The corresponding stack traces are (/Oracle Thin/'s T4CConnection example): > T4CConnection(PhysicalConnection).rollback() line: 1950 > PoolableConnection(DelegatingConnection).rollback() line: 368 > PoolableConnectionFactory.passivateObject(Object) line: 685 > BasicDataSource.validateConnectionFactory(PoolableConnectionFactory) > line: 1559 > BasicDataSource.createPoolableConnectionFactory(ConnectionFactory, > KeyedObjectPoolFactory, AbandonedConfig) line: 1545 > BasicDataSource.createDataSource() line: 1388 > BasicDataSource.getConnection() line: 1044 and > T4CConnection(PhysicalConnection).rollback() line: 1950 > PoolableConnection(DelegatingConnection).rollback() line: 368 > PoolableConnectionFactory.passivateObject(Object) line: 685 > GenericObjectPool.addObjectToPool(Object, boolean) line: 1379 > GenericObjectPool.returnObject(Object) line: 1342 > PoolableConnection.close() line: 90 > PoolingDataSource$PoolGuardConnectionWrapper.close() line: 191 Thus, each successful database transaction is a sequence of: 1. ROLLBACK (connection taken from the pool) 2. do something with the database connection (application code) 3. COMMIT (application code) 4. ROLLBACK (connection closed) (instead of a single COMMIT), while each failed one is a sequence of 1. ROLLBACK (connection taken from the pool) 2. do something with the database connection (application code) 3. ROLLBACK (application code) 4. ROLLBACK (connection closed) (instead of a single ROLLBACK). This behaviour applies an additional pressure to the redo and undo subsystems (particularly, in /Oracle/ case, but the problem holds for any database accessed via /commons-dbcp/, e. g.: I observed the same issue with /MySQL/). *Question 1*: how can I get rid of these extra ROLLBACK's while still having my data source configured with defaultAutoCommit=false (i. e. without the need to manually call setAutoCommit(false) for each connection taken from the data source)? *Question 2* (I'm aware I may be barking up the wrong tree, but still): alternatively, how can I mitigate the issue from /Oracle/ side (i. e. without changing my code or replacing libraries)? Regards, Andrey. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
