Aug 5, 2017

Understanding JVM: Class Loader Sub System - Part 2

First part of class loader sub system talked about the Loading of class files. Next task that is performed by the class loader sub system is Linking.

Linking 

It performs 3 activities:
  • Verification
  • Preparation
  • Resolution

Verification

  • It is the process of ensuring binary representation of class file (output of Loading) is correct or not. Correct means if .class file is properly formatted or not, and it is generated by valid compiler or not.
  • Internally Byte Code Verifier, which is part of Class Loader Sub System, is responsible for this activity.
  • If verification fails, then it will throw the run-time exception, java.lang.VerifyError.

Preparation

  • In preparation phase, JVM will allocate memory and assign default values for class level static variables. For example:
    • For int --> 0
    • For double --> 0.0
    • For boolean -->false
    • For object --> NULL
  • It is important to note here that only default values are assigned in this phase, actual values (as defined in the class will be assigned in initialization phase. That means if a class variable is declared as,  private static int count = 10, 0 will be assigned in the preparation phase.

Resolution

  • All symbolic references are replaced with original direct references from method area. (Method area will be explained in coming articles). For example, consider following code:
 class Test {  
      public static void main(String[] args) {  
           String name = new String("Java Territory");  
           Student s1 = new Student();  
      }  
 }
  • In the above example, class loader sub system loads Test.class, String.class, Student.class and Object.class. The names of these classes are stored in constant pool of Test class.
  • In Resolution phase, these names are replaced with actual references from the method area of JVM.
After Linking is done, Initialization of class files are done.

Intialization
  • After Loading and Linking of class files are done, JVM will assign original values (as declared in the class file) to the class level static variables.
  • Also, static blocks are executed during this phase.
Following diagram explains the functions performed by Class Loader Sub System:
If any error comes Loading, Linking or Initialization, JVM will raise runtime exception, java.lang.LinkageError.

VerifyError is a child class of LinkageError.

This is all for Class Loader Sub System. In next article, I will talk about the types of Class Loaders. Please post your inputs in the comments section.

If you like reading our article, follow us +Java Territory / facebook to stay connected and get notifications for new articles.

Jul 10, 2017

Understanding JVM: Class Loader Sub System - Part 1

Now we know from the previous article that JVM is responsible for loading od the Java class file. Internally Class Loader Sub System performs following steps:
  1. Loading
  2. Linking
  3. Initialization
Loading: Loading means reading .class file data and store corresponding data in method area. For each .class file, JVM will store following information:
  • fully qualified name of class
  • fully qualified name of immediate parent
  • whether .class file represents class/interface/enum
  • methods/constructors/variables information
  • modifiers information
  • constant pool information
After .class object is loaded into memory, JVM then creates the "Class" object for the the same. This object can be used to retrieve class level information like how many methods are there in class, using reflection. 

It is important to note that for every class, only one "Class" object will be created by JVM. Consider following example:

1:  public class Exmaple {  
2:       Student s1 = new Student ();  
3:       Class c1 = s1.getClass();  
4:       Student s2 = new Student ();  
5:       Class c2 = s2.getClass();  
6:  }  

In the above example, s1.getClass() and s2.getClass() will give same object as there is only one object of Class class of Student.

Classloader subsystem first loads class file and stores in method area. Then JVM creates object of Class class.

Next section will be on the second activity performed by Class Loader Sub System, i.e., Linking.
Join us at +Java Territory or facebook to stay updated.

Understanding JVM: Introduction

What are Virtual Machines?

Virtual machine is something which does not have a physical existence, for example, PC calculator. In other words, it is a software simulator of a machine that can perform operation like a physical machine, hence the name - Virtual Machine.

Types of Virtual Machines

There are 2 types of virtual machines:
  1. Hardware based / System based:  These are multiple logical VM, independent of each other, working a single physical VM, example of the same are Kernal Based VM (for Linux), VMware, Cloud Computing, etc. Hardware based VMs results in effective utilization of resources. However it is more related to admin terminology, not programmer.
  2. Application based / Process based / Software based:  These VMs acts as run-time engine to execute a particular programming language application. Example: 
      • JVM - For Java
      • CLR - For .net
      • PVM - For Parrot (scripting language)

Basic architecture Diagram of JVM

JVM is the run time engine to execute Java applications and is part of JRE. It loads and executes application line by lines.

Following is the basic architecture diagram:
Different components in the above diagram will be explained in the coming tutorials. Go to Class Loader Sub System to read first component.

Oct 28, 2016

Introduction to Database Transactions: Isolation Levels

A basic knowledge of transactions is required before proceeding with the below article.
I would recommend to go through Introduction to Database Transactions first.

What are isolation levels?

If you have gone through my previous article, you would know the various problems that comes with transactions, i.e., dirty read, non-repeatable read, overwriting uncommitted Data and phantom read. Isolation levels aims to solve these problems. They determine the strategy to be used while a data is accessed by multiple transactions simultaneously. For example, if a data is read by a transaction, should other transaction running in parallel be allowed to read that data. Similarly, what should happen when one transaction has modified some data but not committed as of yet and other transaction has to use that data. All these different scenarios are handled by specifying the correct isolation level.

Types of Isolation Levels

There are four types of isolation levels:
  • Read uncommitted
  • Read committed
  • Repeatable read
  • Serializable
Below table describes the salient features of each of them:
Isolation LevelDescription
Read uncommitted
  • Transactions can read rows that have been modified by other transactions but not yet committed.
  • Least restrictive isolation level.
  • Read Uncommitted level are usually read-only.
Read committed
  • Transactions cannot read data that has been modified but not committed by other transactions. This prevents "dirty read".
  • Transactions can modify data that has been read by another transactions which have not committed yet, resulting in “non-repeatable reads” or “phantom data”. 
  • Generally uses row-lock.
Repeatable read
  • Transactions cannot read data that has been modified but not committed by other transactions. This prevents "dirty read".  
  • Transactions cannot modify data that has been read by another transactions which have not committed yet. This prevents “non-repeatable reads”. 
  • Other transactions can insert new rows that match the search conditions of statements issued by the current transaction resulting in “phantom data”. 
  • Generally uses row-lock. 
  • Concurrency is lower than READ COMMITTED isolation level since locks are held till the end of a transaction instead of being released at the end of each statement.
Serializable
  • Transactions cannot read data that has been modified but not committed by other transactions. This prevents "dirty read".
  • Transactions cannot modify data that has been read by another transactions which have not committed yet. This prevents “non-repeatable reads”.
  • Other transactions cannot insert new rows that match the search conditions of statements issued by the current transaction until the current transaction completes. This prevents “phantom data”.
  • Range locks are used that match the search conditions executed in a transaction. This blocks other transactions from updating or inserting any rows that would match the search conditions issued by the current transaction.
  • Most restrictive isolation level.
  • Concurrency is lower.

Following tables summarizes the problems solved by each isolation level:
Transaction isolation level
Dirty reads
Non Repeatable reads
Phantom Data
Read uncommitted
Not Solved
Not Solved
Not Solved
Read committed
Solved
Not Solved
Not Solved
Repeatable read
Solved
Solved
Not Solved
Serializable
Solved
Solved
Solved
Things to note:
  • Only one of the isolation level options can be set at a time, and it remains set for that connection until it is explicitly changed.
  • In case of change of isolation level, resources that are read after the change are protected according to the rules of the new level. Resources that are read before the change continue to be protected according to the rules of the previous level.
  • Transaction isolation level does not affect a transaction's ability to see its own changes; transactions can always see any changes they make.

That is it! Thanks for reading. Hope you liked the article. Please do post in the comment section for any query.
Do not forget to follow us at +Java Territory to stay updated.

Oct 22, 2016

Introduction to Database Transactions

A transaction is unit of work that must commit or abort as an atomic unit. By unit of work, we mean a sequence of reads and writes of database objects.
Transaction management means controlling the execution of transactions to ensure data integrity and consistency.

Let’s take an example of bank transaction: Rs. 200 are transferred in Transfer Rs.200 from Account A to Account B. It would normally be done in 2 steps:

Account A (in Rs.)
Account B (in Rs.)

Original Amount
1000
500

STEP 1: Debit Rs.200 from Account A
1000 - 200 = 800
500
SUCCESS
STEP 2: Credit Rs.200 to Account B
800
500
FAIL
Suppose STEP 1 succeeds and STEP 2 fails, final balance in A’s account will be 800. Rs.200 are lost. This is what transaction management aims to solve, i.e., all steps should either succeed or all steps should be rolled-back, otherwise we are left in an inconsistent state. And all these steps (that either should be executed completely or none of them should have any impact on the state of database) are collectively called transactions.

States of Transactions
A transaction in a database can be in one of the following states –
  • Active: Initial state of every 
  • Partially Committed: When a transaction executes all its operations but hasn’t been committed 
  • Failed: If any operation 
  • Aborted: If the transaction fails, then the recovery manager rolls back all its write operations on the database to bring the database back to its original state where it was prior to the execution of the transaction. Transactions in this state are called aborted. The database recovery module can select one of the two operations after a transaction aborts-
    • Re-start the transaction
    • Kill the transaction
  • Committed: If a transaction executes all its operations successfully, it is said to be committed. All its effects are now persisted in the database. 
What are ACID properties ?
A transaction in a database system must maintain Atomicity, Consistency, Isolation, and Durability − commonly known as ACID properties − in order to ensure accuracy, completeness, and data integrity.
  • Atomicity: Either all actions in a transaction are carried out, or none are. There must be no state in a database where a transaction is left partially completed.
  • Consistency: If each transaction is consistent, and the database is initially consistent, then it must remain consistent after the execution of the 
  • Isolation: Transactions are isolated or protected from the effects of other scheduled transactions. When more than one transaction are being executed simultaneously and in parallel, then transactions will be carried out and executed as if it is the only transaction in the system. Final result should be same as if these transactions are executed sequentially.
  • Durability: If a transactions completes successfully, then its effects persist. If a transaction commits but the system crashes before the data could be written on to the disk, then that data will be updated once the system is restored.
Schedule
A schedule is a list of actions from a set of transactions. A well-formed schedule is one where the actions of a particular transaction T are in the same order as they appear in T.
  • A complete schedule is one that contains an abort or commit action for every transaction that occurs in the schedule.
  • serial schedule is one where transactions are executed in a serial manner, one after the other.
  • serializable schedule is a schedule whose effect on any consistent database instance is identical to that of some complete serial schedule
  • equivalent schedule is a schedule that has same result on database state i.e. effect of executing the first schedule is identical to the effect of executing the second schedule.
Anamolies with interleaved execution
Let us consider ways in which a schedule involving two consistency-preserving transactions can leave a consistent database inconsistent.
  • Dirty Read (WR conflict): When a transaction reads a value that is updated by another transaction which has not completed yet.
Example: We have 2 transactions executing in parallel:
TA: Transfer Rs.200 from Account A to Account B.
TB: Transfer Rs.100 from Account C to Account A.

Account A (in Rs.)
Account B (in Rs.)
Account C (in Rs.)
Original Amount
1000
500
200
TA: STEP 1: Debit Rs.200 from Account A
1000 - 200 = 800


TB: STEP 1: Debit Rs.100 from Account C


200 - 100 = 100
TB: STEP 2: Credit Rs.100 to Account A
800 + 100 = 900


TA: STEP 2: Credit Rs.200 to Account B

500 + 200 = 700

Final Amount
900
700
100
Sum of original amount in all accounts = Sum of final amount in all accounts = Rs.1700

Suppose if TA STEP2 fails, then the recovery manager rolls back TA
Account A: Back to Rs.1000 as TA has read original value as Rs.1000.
Account B: Back to Rs.500 as TA has read original value as Rs.500.

So, final amount in the accounts after transaction TA has been rolled back due to failure and transaction TB has been committed.

Account A (in Rs.)
Account B (in Rs.)
Account C (in Rs.)
Final Amount
1000
500
100
Sum of original amount in all accounts != Sum of final amount in all accounts

So, Rs.100 being transferred by Account C has been lost because transaction TB has read value updated by transaction TA which has not been completed yet.
  •  Non-Repeatable Read (RW conflict): When in a transaction a value is read twice and two different results are rendered.
Example: We have 2 transactions executing in parallel:
TA: Reads balance of Account A twice while its execution.
TB: Transfer Rs.100 from Account C to Account A.

Account A (in Rs.)
Account B (in Rs.)
Account C (in Rs.)
Original Amount
1000
500
200
TA: STEP 1: Get balance of Account A
1000


TB: STEP 1: Debit Rs.100 from Account C


200 – 100 = 100
TB: STEP 2: Credit Rs.100 to Account A
1000 + 100 = 1100


TA: STEP 2: Get balance of Account A
1100


  • Overwriting uncommitted Data (WW conflict): When a transaction overwrites the value which has already been modified by another transaction while is still in progress.
Example: We have 2 transactions executing in parallel:
TA: Update the number of correct questions to 15 and incorrect questions to 5.
TB: Update the number of correct questions to 18 and incorrect questions to 2.

Correct Questions
Incorrect Questions
Original Data
10
10
TA: STEP 1: Update the number of correct questions to 15
15

TB: STEP 1: Update the number of correct questions to 18
18

TB: STEP 2: Update the number of incorrect questions to 2

2
TA: STEP 2: Update the number of incorrect questions to 5

5
Final Data
18
5
  • Phantom Read: When a read operation occurs more than one time in same transaction return different number of rows.
Example: We have 2 transactions executing in parallel:
TA: Get number of account whose balance > Rs.500 (twice during its execution).
TB: Transfer Rs.100 from Account C to Account B.

Account A (in Rs.)
Account B (in Rs.)
Account C (in Rs.)
Original Amount
1000
500
200
TA: STEP 1: Get accounts whose balance > Rs.500
1000


TB: STEP 1: Debit Rs.100 from Account C


200 – 100 = 100
TB: STEP 2: Credit Rs.100 to Account B

500 +  100 = 600

TA: STEP 2: Get accounts whose balance > Rs.500
1000
600


Above mentioned anamolies can lead to inconsistent state and may have disastrous impact. To cater these scenarios, isolation levels are used. Read here for more details on Isolation Levels.

That is all on the basics of Transactions. Follow us at +Java Territory to stay updated.