About Question enthuware.ocpjp.v8.2.1158 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

Moderator: admin

Post Reply
schchen2000
Posts: 106
Joined: Mon Mar 28, 2016 11:36 pm
Contact:

About Question enthuware.ocpjp.v8.2.1158 :

Post by schchen2000 »

Code: Select all

  Connection con = DriverManager.getConnection(dbURL);

  //code for enabling transactions

  String updateString =
        "update SALES set T_AMOUNT = 100 where T_NAME = 'BOB'";
  Statement stmt = con.createStatement();
  stmt.executeUpdate(updateString);
  stmt.executeUpdate("update ACCOUNTS set STATUS=1");

  con.commit();  //REPLACE THIS LINE OF CODE
In that code above,
//code for enabling transactions
is meant to be replaced by either con.setAutoCommit(false); or con.setAutoCommit(true);

We are including either con.setAutoCommit(false); or con.setAutoCommit(true); here for the sake of this question. Even without either one of them being included here specifically, con.setAutoCommit(true); is set by default in Java for us.

Is that correct?

Question 1
---------------
Now, in this question, it is not clear from the code whether the auto-commit has been set to true or false.

Case 1: If auto-commit was set to true. In this case, every statement is committed after it completes. Therefore, the call to commit() is not actually required and so it can be replaced with setAutoCommit(true) or even setAutoCommit(false) without any impact.
In the quote immediately above this question, you said "even setAutoCommit(false) without any impact." Why without any impact? Is that because of the following order of reasoning?

The line indicated by (1) below is followed by

a lot of execute statements and all of them will be committed due to the auto commit being true in the line indicated by (1).

By the time we get to the line indicated by (2) below, all the commits have been made and thus the auto commit being false in (2) won't make any impact because all the work has be done at this point.

Is that correct?

Code: Select all


  setAutoCommit(true) // <========== (1)

  String updateString =
        "update SALES set T_AMOUNT = 100 where T_NAME = 'BOB'";
  Statement stmt = con.createStatement();
  stmt.executeUpdate(updateString);
  stmt.executeUpdate("update ACCOUNTS set STATUS=1");

  setAutoCommit(false) // <========== (2)
Thanks.

Schmichael

PS
Sorry about this question being too loaded.

schchen2000
Posts: 106
Joined: Mon Mar 28, 2016 11:36 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by schchen2000 »

Question 2
---------------
Case 2: If auto-commit was set to false. In this case, it is necessary to commit the transaction explicitly. This can be done either by calling con.commit() as shown in the code or by changing the auto-commit mode from false to true. This utilizes the side effect of changing the auto-commit mode of the connection. If the setAutoCommit method is called during a transaction and the auto-commit mode is changed, the transaction is committed. If setAutoCommit is called and the auto-commit mode is not changed, the call is a no-op.
Due to the auto commit being false in line marked by (1) below, all the execute statements are "queued up" for commit. While those in the queue that are waiting to be committed, we can still do roll back at this stage.

Is that correct?

Once they are committed by auto commit being true as indicated by line (2) below, what would then happen if we do the roll back after a commit, i.e. nothing left in the queue after the commit?

Code: Select all


  setAutoCommit(false) // <========== (1)

  String updateString =
        "update SALES set T_AMOUNT = 100 where T_NAME = 'BOB'";
  Statement stmt = con.createStatement();
  stmt.executeUpdate(updateString);
  stmt.executeUpdate("update ACCOUNTS set STATUS=1");

  setAutoCommit(true) // <========== (2)
Many thanks.

Schmichael

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by admin »

schchen2000 wrote:

Code: Select all

  Connection con = DriverManager.getConnection(dbURL);

  //code for enabling transactions

  String updateString =
        "update SALES set T_AMOUNT = 100 where T_NAME = 'BOB'";
  Statement stmt = con.createStatement();
  stmt.executeUpdate(updateString);
  stmt.executeUpdate("update ACCOUNTS set STATUS=1");

  con.commit();  //REPLACE THIS LINE OF CODE
In that code above,
//code for enabling transactions
is meant to be replaced by either con.setAutoCommit(false); or con.setAutoCommit(true);

We are including either con.setAutoCommit(false); or con.setAutoCommit(true); here for the sake of this question. Even without either one of them being included here specifically, con.setAutoCommit(true); is set by default in Java for us.

Is that correct?
Correct.
Question 1
---------------
Now, in this question, it is not clear from the code whether the auto-commit has been set to true or false.

Case 1: If auto-commit was set to true. In this case, every statement is committed after it completes. Therefore, the call to commit() is not actually required and so it can be replaced with setAutoCommit(true) or even setAutoCommit(false) without any impact.
In the quote immediately above this question, you said "even setAutoCommit(false) without any impact." Why without any impact? Is that because of the following order of reasoning?

The line indicated by (1) below is followed by

a lot of execute statements and all of them will be committed due to the auto commit being true in the line indicated by (1).

By the time we get to the line indicated by (2) below, all the commits have been made and thus the auto commit being false in (2) won't make any impact because all the work has be done at this point.

Is that correct?

Code: Select all


  setAutoCommit(true) // <========== (1)

  String updateString =
        "update SALES set T_AMOUNT = 100 where T_NAME = 'BOB'";
  Statement stmt = con.createStatement();
  stmt.executeUpdate(updateString);
  stmt.executeUpdate("update ACCOUNTS set STATUS=1");

  setAutoCommit(false) // <========== (2)
Correct.
If you like our products and services, please help us by posting your review here.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by admin »

schchen2000 wrote:Question 2
---------------
Case 2: If auto-commit was set to false. In this case, it is necessary to commit the transaction explicitly. This can be done either by calling con.commit() as shown in the code or by changing the auto-commit mode from false to true. This utilizes the side effect of changing the auto-commit mode of the connection. If the setAutoCommit method is called during a transaction and the auto-commit mode is changed, the transaction is committed. If setAutoCommit is called and the auto-commit mode is not changed, the call is a no-op.
Due to the auto commit being false in line marked by (1) below, all the execute statements are "queued up" for commit. While those in the queue that are waiting to be committed, we can still do roll back at this stage.

Is that correct?

Once they are committed by auto commit being true as indicated by line (2) below, what would then happen if we do the roll back after a commit, i.e. nothing left in the queue after the commit?

Code: Select all


  setAutoCommit(false) // <========== (1)

  String updateString =
        "update SALES set T_AMOUNT = 100 where T_NAME = 'BOB'";
  Statement stmt = con.createStatement();
  stmt.executeUpdate(updateString);
  stmt.executeUpdate("update ACCOUNTS set STATUS=1");

  setAutoCommit(true) // <========== (2)
Many thanks.

Schmichael
Correct.
If you like our products and services, please help us by posting your review here.

schchen2000
Posts: 106
Joined: Mon Mar 28, 2016 11:36 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by schchen2000 »

Many thanks for all the answers. I would still like to get this

"what would then happen if we do the roll back after a commit, i.e. nothing left in the queue after the commit? "

from Question 2 answered if you could. Please.

Thanks again.

Schmichael

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by admin »

If you call commit if the connection is in auto-commit mode, then you will get an exception: https://docs.oracle.com/javase/7/docs/a ... tml#commit()
If you like our products and services, please help us by posting your review here.

schchen2000
Posts: 106
Joined: Mon Mar 28, 2016 11:36 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by schchen2000 »

admin wrote:If you call commit if the connection is in auto-commit mode, then you will get an exception: https://docs.oracle.com/javase/7/docs/a ... tml#commit()
I's asking what would happen when a roll back is done after everything is committed? I know it's not sensible to do that but just curious as part of the question I asked earlier.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by admin »

Same with rollback. If the connection is in auto-commit mode, you will get an exception. If not, nothing will happen. Just check the JavaDoc description of rollback method https://docs.oracle.com/javase/7/docs/a ... l#rollback().
If you like our products and services, please help us by posting your review here.

schchen2000
Posts: 106
Joined: Mon Mar 28, 2016 11:36 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by schchen2000 »

admin wrote:Same with rollback. If the connection is in auto-commit mode, you will get an exception. If not, nothing will happen. Just check the JavaDoc description of rollback method https://docs.oracle.com/javase/7/docs/a ... l#rollback().
In other words, once the commit is done, it's gone. Once it's gone, it's gone and you can no longer do any roll back. If one insists on attempting to roll back after the commit, an exception is triggered.

Is that correct?

Thank you.

Schmichael

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by admin »

No, there is no exception if you call rollback after a commit.
BTW, given that you've already called commit successfully, that means the connection is not in auto-commit mode.
I would again suggest you to go through the JavaDoc link that I gave above.
-Paul.
If you like our products and services, please help us by posting your review here.

schchen2000
Posts: 106
Joined: Mon Mar 28, 2016 11:36 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by schchen2000 »

admin wrote:No, there is no exception if you call rollback after a commit.
BTW, given that you've already called commit successfully, that means the connection is not in auto-commit mode.
I would again suggest you to go through the JavaDoc link that I gave above.
-Paul.
Oh, I did not know that. Thanks, Paul.

Schmichael

thodoris.bais
Posts: 25
Joined: Sat Jun 03, 2017 4:56 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by thodoris.bais »

If the setAutoCommit method is called during a transaction and the auto-commit mode is changed, the transaction is committed. If setAutoCommit is called and the auto-commit mode is not changed, the call is a no-op.
I am not sure whether I fully understand this one. Could you please explain with a code example?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by admin »

1. lets say you make the auto commit mode false by calling con.setAutoCommit(false)
2. You start a firing querries and updates on the connection by calling con.executeUpdate(...)
3. Now, to commit the changes to the database, you should call con.commit(). But instead of calling commit, what if you call con.setAutoCommit(true)?
By calling con.setAutoCommit(true), you changed the status of auto commit from false to true. This will automatically cause the existing transaction to be committed. So there is no need to call con.commit() if you call con.setAutoCommit(true) in this case.
If you like our products and services, please help us by posting your review here.

thodoris.bais
Posts: 25
Joined: Sat Jun 03, 2017 4:56 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by thodoris.bais »

Given that con.setAutoCommit(false); would have the same impact, shouldn't we change the question's format to accept both con.setAutoCommit(false); and con.setAutoCommit(true); as correct answers?

I see it a bit confusing now that one is forced to select one among the fore-mentioned two.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1158 :

Post by admin »

No, con.setAutoCommit(false); will not have the same impact in this case. This is explained in detail in the explanation.
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: No registered users and 45 guests