Understanding Differences in Log Output

[Graeme]

Hi,

I am currently using log4jdbc to compare the SQL queries being used in two version of the same program. One version is older than the other which we want to stop using. Before we do I want to log the JDBC calls to ensure no functionality is being lost or changed.

After running log4jdbc on both version with the same "log4j.properties" file the output naturally differed in line numbers, instances and date. After removing those variables the following differences were still noted:

The number beginning each line can be different between the two programs:
"10. select 1"
"8. select 1"

"setAutoCommit" becomes "getAutoCommit" in the newer version:
"Connection.getAutoCommit() returned true"
"Connection.setAutoCommit(true) returned"

"isClosed" appears in the new version but not the older despite no calls for "isClosed" being found in the code:
"Connection.isClosed() returned false"

Can anyone explain how these differences come about?

Thanks,
Graeme

[Arthur Blake]

The number at the start is the connection number, so whatever program has the bigger number is using more connections for some reason.

Not knowing the nature of your program or how deterministic it is from run to run, it's hard to say if this is an important difference or not.

If the second program has a lower number it could for example indicate changes that were optimizations to use less connections or bug fixes of connection leaks  (or not...)

You say that there are no calls in your code to isClosed, but does your code use any kind of database layer, like a connection pool or ORM?

That might be where the call is coming from.

Changing from setAutoCommit to getAutoCommit sounds like a change in a dependent library that is checking if auto commit is already set and not setting it if so.

I don't know if the java code for which you've lost the source has been obfuscated, but you could also potentially look at decompiling the class files from the original java code and comparing the differences for changes. There are some really good tools out there for doing that kind of stuff. That would get you a lot more information.

--
You received this message because you are subscribed to the Google Groups "log4jdbc" group.
To view this discussion on the web visit https://groups.google.com/d/msg/log4jdbc/-/WXTmvDPIIQ8J.
To post to this group, send email to log4...@googlegroups.com.
To unsubscribe from this group, send email to log4jdbc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/log4jdbc?hl=en.

[Graeme]

Thanks for the quick and helpful reply.

Now that I am logging connection open and close events the number at the beginning of the line makes sense now. The code does appear to use a connection pool and it makes sense that there could be differences in dependent libraries that call extra JDBC commands.

At this point in time I am only interested in high level changes. Decompiling the code would provide more information but it then becomes even harder to compare syntax (difference in formatting and comments and wrongly decompiled code) then even harder to compare at a run time level (logical paths, method calls and variables). Even if changes are found the knowledge for why it has changed has also been lost.

The main function of the program is to import data into databases so thankfully all the SQL commands are still the same. Before I declared the newer version functionally the same as the older version I thought I should gain a better understanding of the other differences in the log files.

Thanks again,
Graeme

On Monday, 14 May 2012 16:47:39 UTC+1, Arthur Blake wrote:

The number at the start is the connection number, so whatever program has the bigger number is using more connections for some reason.

Not knowing the nature of your program or how deterministic it is from run to run, it's hard to say if this is an important difference or not.

If the second program has a lower number it could for example indicate changes that were optimizations to use less connections or bug fixes of connection leaks  (or not...)

You say that there are no calls in your code to isClosed, but does your code use any kind of database layer, like a connection pool or ORM?

That might be where the call is coming from.

Changing from setAutoCommit to getAutoCommit sounds like a change in a dependent library that is checking if auto commit is already set and not setting it if so.

I don't know if the java code for which you've lost the source has been obfuscated, but you could also potentially look at decompiling the class files from the original java code and comparing the differences for changes. There are some really good tools out there for doing that kind of stuff. That would get you a lot more information.

On Mon, May 14, 2012 at 11:32 AM, Graeme wrote:

Hi,

I am currently using log4jdbc to compare the SQL queries being used in two version of the same program. One version is older than the other which we want to stop using. Before we do I want to log the JDBC calls to ensure no functionality is being lost or changed.

After running log4jdbc on both version with the same "log4j.properties" file the output naturally differed in line numbers, instances and date. After removing those variables the following differences were still noted:

The number beginning each line can be different between the two programs:
"10. select 1"
"8. select 1"

"setAutoCommit" becomes "getAutoCommit" in the newer version:
"Connection.getAutoCommit() returned true"
"Connection.setAutoCommit(true) returned"

"isClosed" appears in the new version but not the older despite no calls for "isClosed" being found in the code:
"Connection.isClosed() returned false"

Can anyone explain how these differences come about?

Thanks,
Graeme

--
You received this message because you are subscribed to the Google Groups "log4jdbc" group.
To view this discussion on the web visit https://groups.google.com/d/msg/log4jdbc/-/WXTmvDPIIQ8J.
To post to this group, send email to log4...@googlegroups.com.

To unsubscribe from this group, send email to log4jdbc+unsubscribe@googlegroups.com.