You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Fox <th...@seitenbau.com> on 2018/09/03 03:32:05 UTC
Re: svn commit: r1839284 - in /db/torque/torque4/trunk:
torque-runtime/src/main/java/org/apache/torque/
torque-runtime/src/main/java/org/apache/torque/oid/
torque-runtime/src/main/java/org/apache/torque/util/
torque-runtime/src/test/java/org/apache/torque/...
Thomas,
I'm sorry but I do not understand the state kept in TorqueConnectionImpl.
As I understand it, TorqueConnectionImpl.committed and TorqueConnectionImpl.rolledBack keep track of whether there could be outstanding operations in a transaction. So when one calls close() on a connection with uncommitted changes these get rolled back. But what if one calls commit() and then does other operations on the connection? As I understand the javadoc of java.sql.Connection, this is legal (maybe I'm wrong). But the current logic in TorqueConnectionImpl would not do any rollback on close() then.
And what id autocommit is true? Should there be any rollback attempt in this case? And what if the user switches from autoaommit to non autocommit in the midst of doing database operation?
These are just some random questions, in no way complete. In short, I am not sure whether one wants to get involved in the (perhaps complicated) state keeping logic of java.sql.Connection.
And does TorqueCoonnectionImpl keep the contract of java.sql.Connection.close()? It says in https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#close()that close() would release all resources, but TorqueConnectionImpl does more than that. However, I know other frameworks, e.g. Connection pools, which do other stuff on close() to guarantee a clean connection, but personally I'm not happy about that either.
Just a not-well-thought-through idea: Perhaps one can solve some of these issues if TorqueConnection would not inherit from java.sql.Connection, but would be a different object wrapping a java.sql.Connection, with a different contract, like:
public class TorqueTransactionConnection implements AutoCloseable
{
private java.sql.Connection connection;
public TorqueTransactionConnectionImpl()
{
connection = TransactionManagerImpl.begin();
}
public void commit()
{
if (connection == null)
{
throw new IllegalStateException("already closed");
}
TorqueTransactionConnectionImpl.commit(connection);
connection = null;
}
public void rollback()
{
// analogous to close
}
public void close()
{
rollback();
}
}
Not sure if that idea works through, though.
Thomas
Re: svn commit: r1839284 - in /db/torque/torque4/trunk:
torque-runtime/src/main/java/org/apache/torque/
torque-runtime/src/main/java/org/apache/torque/oid/
torque-runtime/src/main/java/org/apache/torque/util/
torque-runtime/src/test/java/org/apache/torque/...
Posted by Thomas Vandahl <tv...@apache.org>.
On 9/11/18 5:41 AM, Thomas Fox wrote:
> Another idea: Not TorqueConnectionImpl.rollback() and TorqueConnectionImpl.commit() set the flag to not rollback on close(), but TransactionImpl.rollback() and TransactionImpl.commit(). So in this case the user can commit() and rollback() on the connection to his heart's content, but only a call on TorqueConnectionImpl.commit()/.rollback()(which closes the connection anyway) changes the connection close behavior. What do you think?
That sounds reasonable. The context is well-defined and the behavior can
be documented easily. I'll give it a try and see how it goes.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: svn commit: r1839284 - in /db/torque/torque4/trunk:
torque-runtime/src/main/java/org/apache/torque/
torque-runtime/src/main/java/org/apache/torque/oid/
torque-runtime/src/main/java/org/apache/torque/util/
torque-runtime/src/test/java/org/apache/torque/...
Posted by Thomas Fox <th...@seitenbau.com>.
On 9. 7. 2018, Thomas Vandahl wrote:
> On 9/6/18 7:03 AM, Thomas Fox wrote:
> > Ok, but should we not reset the committed and rolledBack Flag when the user could have issued further statements after a commit/rollback, e.g. when connection.createStatement() ist called?
>
> Yes, I agree - at least in the general case. I our case, however,
> TorqueConnection is returned from our TransactionManagerImpl which
> happens to *close* the connection right after commit.
I agree. In Torque's current usage, there is no need for handling operations after commit or rollback. However, as the connection is passed to the user, some users might be tempted to call rollback and commit on the connection itself, and things will become strange then (no rollback on connection.close() for example).
> I was thinking that probably the easiest way to handle the connection
> state is to rollback unconditionally before close. If work had been
> committed, no harm would be done. If not, we need to rollback anyway.
> WDYT? Do you have any idea of the performance implications?
Probably this will work in most cases. I'm not sure whether it will work in all cases. I have no idea about performance implications though I suspect them to be small.
Personally I like such behavior to be configurable for handling edge cases.
Another idea: Not TorqueConnectionImpl.rollback() and TorqueConnectionImpl.commit() set the flag to not rollback on close(), but TransactionImpl.rollback() and TransactionImpl.commit(). So in this case the user can commit() and rollback() on the connection to his heart's content, but only a call on TorqueConnectionImpl.commit()/.rollback()(which closes the connection anyway) changes the connection close behavior. What do you think?
Thomas
Re: svn commit: r1839284 - in /db/torque/torque4/trunk:
torque-runtime/src/main/java/org/apache/torque/
torque-runtime/src/main/java/org/apache/torque/oid/
torque-runtime/src/main/java/org/apache/torque/util/
torque-runtime/src/test/java/org/apache/torque/...
Posted by Thomas Vandahl <tv...@apache.org>.
On 9/6/18 7:03 AM, Thomas Fox wrote:
> Ok, but should we not reset the committed and rolledBack Flag when the user could have issued further statements after a commit/rollback, e.g. when connection.createStatement() ist called?
Yes, I agree - at least in the general case. I our case, however,
TorqueConnection is returned from our TransactionManagerImpl which
happens to *close* the connection right after commit.
I was thinking that probably the easiest way to handle the connection
state is to rollback unconditionally before close. If work had been
committed, no harm would be done. If not, we need to rollback anyway.
WDYT? Do you have any idea of the performance implications?
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: svn commit: r1839284 - in /db/torque/torque4/trunk:
torque-runtime/src/main/java/org/apache/torque/
torque-runtime/src/main/java/org/apache/torque/oid/
torque-runtime/src/main/java/org/apache/torque/util/
torque-runtime/src/test/java/org/apache/torque/...
Posted by Thomas Fox <th...@seitenbau.com>.
On 05.09.18 19:30, Thomas Vandahl wrote:
> On 05.09.18 19:19, Thomas Vandahl wrote:
>> On 03.09.18 05:32, Thomas Fox wrote:
>>> As I understand it, TorqueConnectionImpl.committed and TorqueConnectionImpl.rolledBack keep track of whether there could be outstanding operations in a transaction. So when one calls close() on a connection with uncommitted changes these get rolled back. But what if one calls commit() and then does other operations on the connection? As I understand the javadoc of java.sql.Connection, this is legal (maybe I'm wrong). But the current logic in TorqueConnectionImpl would not do any rollback on close() then.
>>
>> I will have to check what the contract actually is. The implementation
>> right now is more or less a 80% solution.
>
>The Javadoc of close() actually says:
>
>It is strongly recommended that an application explicitly commits or
>rolls back an active transaction prior to calling the close method. If
>the close method is called and there is an active transaction, the
>results are implementation-defined.
>
>As I read it, this gives us some freedom in the "definition of our
>implementation".
Ok, but should we not reset the committed and rolledBack Flag when the user could have issued further statements after a commit/rollback, e.g. when connection.createStatement() ist called?
Thomas
Re: svn commit: r1839284 - in /db/torque/torque4/trunk:
torque-runtime/src/main/java/org/apache/torque/
torque-runtime/src/main/java/org/apache/torque/oid/
torque-runtime/src/main/java/org/apache/torque/util/
torque-runtime/src/test/java/org/apache/torque/...
Posted by Thomas Vandahl <tv...@apache.org>.
On 05.09.18 19:19, Thomas Vandahl wrote:
> On 03.09.18 05:32, Thomas Fox wrote:
>> As I understand it, TorqueConnectionImpl.committed and TorqueConnectionImpl.rolledBack keep track of whether there could be outstanding operations in a transaction. So when one calls close() on a connection with uncommitted changes these get rolled back. But what if one calls commit() and then does other operations on the connection? As I understand the javadoc of java.sql.Connection, this is legal (maybe I'm wrong). But the current logic in TorqueConnectionImpl would not do any rollback on close() then.
>
> I will have to check what the contract actually is. The implementation
> right now is more or less a 80% solution.
The Javadoc of close() actually says:
It is strongly recommended that an application explicitly commits or
rolls back an active transaction prior to calling the close method. If
the close method is called and there is an active transaction, the
results are implementation-defined.
As I read it, this gives us some freedom in the "definition of our
implementation".
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: svn commit: r1839284 - in /db/torque/torque4/trunk:
torque-runtime/src/main/java/org/apache/torque/
torque-runtime/src/main/java/org/apache/torque/oid/
torque-runtime/src/main/java/org/apache/torque/util/
torque-runtime/src/test/java/org/apache/torque/...
Posted by Thomas Vandahl <tv...@apache.org>.
On 03.09.18 05:32, Thomas Fox wrote:
> As I understand it, TorqueConnectionImpl.committed and TorqueConnectionImpl.rolledBack keep track of whether there could be outstanding operations in a transaction. So when one calls close() on a connection with uncommitted changes these get rolled back. But what if one calls commit() and then does other operations on the connection? As I understand the javadoc of java.sql.Connection, this is legal (maybe I'm wrong). But the current logic in TorqueConnectionImpl would not do any rollback on close() then.
I will have to check what the contract actually is. The implementation
right now is more or less a 80% solution.
> And does TorqueCoonnectionImpl keep the contract of java.sql.Connection.close()? It says in https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#close()that close() would release all resources, but TorqueConnectionImpl does more than that. However, I know other frameworks, e.g. Connection pools, which do other stuff on close() to guarantee a clean connection, but personally I'm not happy about that either.
Actually, the standard contract of a JDBC connection is already bent
badly by all connection pools that I know. I think we are not worse.
> Just a not-well-thought-through idea: Perhaps one can solve some of these issues if TorqueConnection would not inherit from java.sql.Connection, but would be a different object wrapping a java.sql.Connection, with a different contract, like:
My goal was to change as little as possible in the rest of the code. If
we introduce our own connection object, all signatures of our methods
taking java.sql.Connection must be changed. I see advantages and
disadvantages in this approach. I just didn't want to get into it.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org