db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Wilder <0505...@acadiau.ca>
Subject Derby-213 Chat Transcript June 22
Date Wed, 22 Jun 2005 18:53:00 GMT
DERBY-213 chat summary for June 22, 2005

The entirety of our chat session this time was devoted to further 
analysis of the Derby commit outline. The eventual objective of this 
outline is to establish a document that can be used as a standard for 
Derby commit behavior. Many of the problems faced by Kathey and I stem 
from this issue. During this conversation Kathey and I:

- Decided that the outline would benefit from a bulleted summary.
- Established that information regarding multiple update counts, output 
parameters, calls to connection.setAutoCommit() and batch behavior were 
missing and needed to be included.
- Determined that it would be beneficial to split Statement completion 
behavior into simple and advanced cases.

As before stay tuned for the "semantic challenge", when we release our 
proposed outline.

Philip
#############################################
DERBY-213 chat transcript for June 22, 2005

[09:32] kmarsden: hi philip
[09:32] Bogomips: Hello
[09:32] kmarsden: trillian just refuses to start at all this morning. 
I'll have to reboot but will use Xchat for the moment.
[09:32] kmarsden: OK. I think we are getting close.
[09:33] Bogomips: Any suspicions as to what we are lacking?
[09:33] kmarsden: Your first draft said that commit occurs
[09:34] kmarsden: On the next call to an execute method by any statement
[09:34] kmarsden: or when the staement completes
[09:35] Bogomips: The JDBC API Tutorial book gives a pretty solid 
definition of completeness if we deem it trustworthy.
[09:35] Bogomips: At least the 2nd edition did. I can't speak for the 3rd.
[09:35] kmarsden: so if that is ture, I think that your new summary just 
goes under the When the statement completes part.
[09:36] kmarsden: Your new summary doesn't include the " On the next 
call to an execute method by any statement"
[09:36] kmarsden: I think
[09:36] Bogomips: True.
[09:37] kmarsden: I don't see the quote about statement execution in 
your quotes section
[09:37] kmarsden: this part
[09:37] kmarsden:  " On the next call to an execute method by any statement"
[09:37] kmarsden: although that is the way I have always thought it worked
[09:38] Bogomips: "The commit occurs when the statement completes or the 
next execute occurs, whichever comes first"
[09:39] Bogomips: It does not specify which statement the execute comes 
from but since commits happen at the connection level I think this is 
the only plausible interpretation.
[09:40] kmarsden: Is this how embedded behaves in practice?
[09:40] Bogomips: You might consider looking at my email reply to Daniel 
Debrunner Re: forMetaData
[09:41] Bogomips: Basically it says, if you open a second ResultSet 
belonging to a second Statement it will close the first ResultSet.
[09:41] Bogomips: when you have CLOSE_CURSORS_AT_COMMIT
[09:42] kmarsden: right. The commit is always at the connection level.
[09:42] kmarsden: ok
[09:42] kmarsden: So for our autocommit summary we have autocommit occurs
[09:43] kmarsden: 1)  On the next execution of  any statement
[09:43] kmarsden: 2) When any result set is closed
[09:43] kmarsden: 3) When any statement completes
[09:43] kmarsden: and then our summary of statement completion under that.
[09:43] kmarsden: does that sound right?
[09:44] Bogomips: 2) Incorrect. In the case of multiple ResultSets the 
commit will only when all the other ResultSets are already closed.
[09:44] kmarsden:  I thout  any time you explicitly close a result set 
it sends a commit.
[09:44] kmarsden: but let me check.
[09:45] Bogomips: "In rare cases where the method execute is called, 
however, a statement is not complete until all the result sets or update 
counts it generated have been retrieved."
[09:46] Bogomips: Sorry, I suppose that is more regarding completeness.
 
 At the moment however, Embedded does check to insure that all other 
ResultSets associated with a Statement are closed.
[09:47] kmarsden: ok. Just curious. is this how the embedded logic 
works.  Only flows commit on close if all the resultsets are closed
[09:47] kmarsden: ?
[09:47] Bogomips:           if (dynamicResults != null) {
                for (int i = 0; i < dynamicResults.length; i++) {
                     EmbedResultSet lrs = dynamicResults[i];
                     if (lrs == null)
                          continue;
                     if (lrs.isClosed)
                          continue;
                     if (lrs == closingLRS)
                          continue;
 
                     // at least one still open so no commit now.
                     return;
                }
           }
[09:48] kmarsden: ok
[09:49] kmarsden: On our statement completion summary I think we need to 
talk about output parameters and update counts for multiple results.
[09:49] kmarsden: Rather than Multiple ResultSet as a bullet
[09:50] kmarsden: I would say have
[09:50] Bogomips: Hmmm.... Good point.
 The quote from the JDBC book talks about update counts but I do not 
mention it explicitly. I don't have much info on output parameters.
[09:50] kmarsden: Advanced cases - Multiple Results or output parameters
[09:51] kmarsden: A statement that returns multiple results completes 
when ..
[09:51] kmarsden: 1) Each result set has been retreived as rdescribed in 
Query above
[09:52] kmarsden: 2) Each update count has been retrieved for inserts or 
delete results.
[09:52] kmarsden: 3) All output parameters have been retrieved
[09:52] kmarsden: chnage the Each to All
[09:53] kmarsden: When you have multiple results in a callable statement 
you call getMoreResults to get the next result
[09:53] Bogomips: Can we confirm the Statement of all output parameters? 
What about INOUT parameters?
[09:54] kmarsden: It seems to me if you have an INOUT parameter and you 
don't retrieve it with callableStatement.getInt() or whatever the 
statement is not yet complete.
[09:54] kmarsden: at least that's how I read it.
[09:55] Bogomips: I suppose we can interpret any form of output as part 
of "all its results have been returned" then your reasoning follows.
[09:57] kmarsden: in the setAutocommit javadoc it is explicit
[09:57] kmarsden: In these cases, the commit occurs when all results and
[09:57] kmarsden: output parameter values have been retrieved.
[09:57] kmarsden: do you think?
[09:58] Bogomips: Yes, you are right.
[09:58] kmarsden: Another time autocommit can happen for our top level 
bullets is when setAutocommit is called.
[09:58] Bogomips: As an aside, I did look at the JDBC 4.0 draft and it 
didn't appear to address any of our concerns.
[09:59] kmarsden: With derby for setAutocommit I think we only send 
commit if the autocommit setting changes.
[09:59] kmarsden: so if it is already autocommit=true and somebody calls 
setAutoCommit(true)  no commit is sent.
[09:59] Bogomips: Should "If this method is called during a transaction, 
the transaction is committed." be interpreted as it will now auto-commit 
in the future, or it will auto-commit immediately.
[10:00] kmarsden: now
[10:00] Bogomips: k
[10:00] kmarsden: For instance if I had autocommit=fale and change it to 
true, a commit is really needed
[10:02] Bogomips: What if you do the opposite?
[10:02] Bogomips: true to false?
[10:02] kmarsden: it should still send a commit
[10:02] Bogomips: k
[10:02] kmarsden: and if you read the spec, we really should send a 
commit when it goes true -> true
[10:02] kmarsden: or false-> false
[10:03] Bogomips: yep...
[10:03] kmarsden: but  historically this caused trouble in practice, so 
I think that is why it was changed for derby.
[10:03] Bogomips: I would be most impressed if non-database devlopers 
would even notice :-)
[10:04] kmarsden: OK so in summary we  have this.
[10:04] kmarsden: autocommit occurs ...
[10:05] kmarsden: 1) On the next execution of any statement.
[10:06] kmarsden: 2) When the statement completes.
[10:07] kmarsden: Single result set
[10:08] kmarsden: Single insert/update/delete
[10:08] kmarsden: Multiple results or output parameters
[10:09] kmarsden: We might have to think here about batch updates too #:(
[10:09] kmarsden: shoot
[10:10] Bogomips: :-s
[10:11] Bogomips: I believe the JDBC book says that commits for batch 
updates are DBMS dependent.
[10:12] kmarsden: ok.  We can leave analyis of that to later then. It 
would be good to have it documented for future generations.
[10:13] kmarsden: ok. then. You want to take another shot at our draft.  
I think you still want to include your quotes and questions.
[10:13] kmarsden: I am still a little uncomfortable with 1) On the next 
execution of any statement.
[10:14] kmarsden: I think in fact it might be that the execution closes 
the result set and then it is the close that drives the commit.
[10:14] kmarsden: no maybe that's not right. we will just leave it as 
you hae it and see what folks say
[10:15] Bogomips: All the setCommit says is "the next execution". And in 
my example to Dan I never close a ResultSet. The first ResultSet is 
closed simply because the second on is open.
 
 I could modifiy the test to use an insert statement insted.
 
[10:16] Bogomips: However, all that proves is the way embedded did it, 
no the way it should be done :-S
[10:16] kmarsden: the one I sent you with the metadata?
[10:17] Bogomips: I created a similar test, also in the Dan email actually.
 
[10:17] kmarsden: let me look. I have to confess since Dan answered I 
didn't look carefully enough.
[10:18] Bogomips: Statement s1 = 
conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, 
ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT);
 ResultSet rs1 = s1.executeQuery("select * from " + tablename);
 DatabaseMetaData dbmd = conn.getMetaData();
 ResultSet rs2 = dbmd.getCatalogs();
 
 /*
 Interestingly a call to rs1.next() here would not throw an exception 
because the call from the Server is recognized as a MetaDatabase 
Statement call.
 */
 
 while (rs2.next());
 /*
 When the ResultSet finishes the client will initiate an autocommit that 
bypasses the forMetaData logic, closing rs1.
 */
 
 rs1.next()
[10:19] Bogomips: The test works fine on Embedded but fails from the Client.
[10:19] Bogomips: Didn't check DerbyNet
[10:20] kmarsden: It would probably be the same.
[10:20] Bogomips: That would be my hunch as well.
[10:21] Bogomips: In any case, I will try to get the changes to you asap.
[10:21] Bogomips: Hopefully we can get a draft out to the dev community 
before the end of today.
[10:23] kmarsden: So we added this morning.  setAutocommit, output 
parameters, Expanding Multiple ResultSets to Multiple Results
[10:23] kmarsden: anything else?
[10:23] Bogomips: Might not hurt to mention BatchUpdates even if our 
Results are hazy.
[10:24] Bogomips: Perhaps that is something that the community can resolve.
[10:24] Bogomips: Also, I have been toying around with Callable 
Statements using the callable testing class as an example but I didn't 
see any examples of multiple ResultSets returned.
[10:25] Bogomips: You wouldn't happen to know where I could find such an 
example would you?
[10:26] kmarsden: Do you think  an update count would be considered 
"retrieved when getMoreResults() was called or when getUpdateCount() is 
called?
[10:26] kmarsden: I think getUpdateCount but we should make that  clear.
[10:27] kmarsden: Yes examples should be in the test lang/procedure.java
[10:28] Bogomips: agreed.
 
 Excellent, thank you.
[10:29] Bogomips: Alright, if somehow I finish both the draft and multi 
ResultSet testing, I'll move on to making a solution for the 
DatabaseMetaData issue.
 
 Between the three of those they should keep me busy for a while.
[10:30] kmarsden: OK. Tuesday ok? with occasional chats in between if 
issues arise?
[10:30] kmarsden: or you can send me draft
[10:31] kmarsden: or the list
[10:32] Bogomips: I will send you one more draft. With your approval, 
which hopefully means the document is satisfactory to both of us, we'll 
send it to the list.
[10:32] kmarsden: ok. good deal. 
[10:33] Bogomips: Give the list until monday perhaps (or until any 
outstanding issues are resolved) and then attempt to implement any 
changes suggested from the list, before implementing the needed changes 
in the code.
[10:34] kmarsden: I am not sure I understand.
[10:35] Bogomips: Sorry, let me try again.
 
[10:35] kmarsden: you mean update the summary with  the input from the 
list before we code?
[10:37] Bogomips: - Submit to you for approval
 - Resolve any issues you find
 -Obtain your approval
 - Submit to Dev list
 - Resolve any issues Dev list finds
 - Obtain approval from the dev-list.
[10:38] kmarsden: k
[10:38] kmarsden: This one when complete should go to vote.
[10:38] Bogomips: - Use our new list to verify that the client matches 
our expectations
 - if not fix the client to do so.
[10:39] Bogomips: One unified interpretation of the JDBC specs could be 
useful.
[10:39] Bogomips: :-)
[10:39] kmarsden: right.  And some things can be deferred and new bugs 
filed, like the databasemetadata stuff, since it is already broken in 
client.
[10:39] kmarsden: Yes, Really call out Lance
[10:39] kmarsden: 's attention on this.
[10:41] kmarsden: the need for Lance's attention that is
[10:42] kmarsden: ok. Philip.  I am off.
[10:42] Bogomips: Alright, I'll get to it.
 Talk to you later
[10:43] kmarsden: Once we get this into words it won't be that hard to 
code.    It seems to be understanding our destination that is at issue 
with this one.
[10:44] Bogomips: indeed

Mime
View raw message