Database Systems

Transaction Isolation Levels:- Defines the scope of data visibility between 2 or more concurrent transactions.



READ UNCOMITTED 


Transactions can read uncommitted (garbage/dirty) data. 
Provides higher throughput. No Locking/Synchronization.
Dirty read is possbile.
Not supported in Oracle


READ COMITTED


Transactions can read only commited data but that data can change during the transaction life cycle.
Provides higher throughput/ No locking Synchronization.
On every read you may get different data.
Oracle Database meets the READ COMMITTED isolation standard. 
This is the default mode for all Oracle Database applications.


REPEATABLE READ


Transactions will get the same data (in rows) for every read. But there may be new rows.
No protection against INSERTS from other transactions.
At any point in a trasaction the read rows are locked so on future reads there may be new rows.
High chances of DEADLOCK. Performance hit (Low throughput)
Oracle Database does not normally support this isolation level, except as provided by SERIALIZABLE.


SERIALIZABLE


Transactions lock/synchronize on the table. 
At any point in the given transaction always same data is read. There are no new rows.
Protects against INSERTS from other transactions.
Very High chances of DEADLOCK. Very low throughput.
Oracle Database does not normally support this isolation level, except as provided by SERIALIZABLE.


Practically, transaction isolation level => READ COMMITTED on the database + use SELECT FOR - UPDATE OR TABLE LOCKING (for data synchronization)


http://docs.oracle.com/cd/B13789_01/appdev.101/b10795/adfns_sq.htm#1024753




SELECT FOR - UPDATE


Use it for locking selective rows that you are working on.
The lock is released on commit or rollback.


-------------------------------------------------------------------------------------------------------------------------------------------------------


CURSORS - is a view of data (window of data)


IMPLICIT -  DML's are implicit cursor (Select/update). DB behind the scenes will start a cursor for every SELECT or UPDATE


EXPLICIT - They can be used in the apps like ProC or in Stored Procs etc where you explicityly define a cursor and then provide a query for data selection.




STATIC  - opens a new cursor every time a new query comes in to the DB.


DYNAMIC - Reuses the same cursor for the similar (with parameters) or same queries.
Database System will create such cursors (process) in shared area. By doing this Databases optimize resource allocation by sharing resources.


Statement s = new Connection.createStatement()

Will always create a new static cursor
Database will never spend time looking for whether the cursor (for query) already exists.

Prepared Statement p = Connection.prepareStatement()

Will check with the database if the compiled query (cursor) already exists. If it does then
the database will returns the existing cursor context.
On first run it will always create a new statement since it wont exist.

Concurency

Context Switches involved in notify notifyAll and conditional notify.

- Conditional Notify () works best.
- A signal from Notify () can be easily missed - see how
- NotifyAll() wakes up all threads and puts them into runnable state. Hence involves context switches (for each thread woken up)


Antipattern

http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns

Static Imports (since Java 5.0) 

Static import is a feature introduced in the Java programming language that allows members (fields and methods) defined in a class as public static to be used in Java code without specifying the class in which the field is defined. This feature was introduced into the language in version 5.0.

The feature provides a typesafe mechanism to include constants into code without having to reference the class that originally defined the field. It also helps to deprecate the practice of creating a constant interface: an interface that only defines constants then writing a class implementing that interface, which is considered an inappropriate use of interfaces^[1].

import static java.lang.Math.*;

import static java.lang.Math.PI;

For custom constants Create a Constant class 

BINARY semaphore:

DO WAIT : SSC

Synchronize - Spin (while:signal notset to true -> this.wait()) - Clear (set signal to false)

DONOTIFY: SSN
Synchronize - Signal( set signal to true) - Notify

public class QueueObject {

  private boolean isNotified = false;

  public synchronized void doWait() throws InterruptedException {
    while(!isNotified){
        this.wait();
    }
    this.isNotified = false;
  }

  public synchronized void doNotify() {
    this.isNotified = true;
    this.notify();
  }

  public boolean equals(Object o) {
    return this == o;
  }
}

Garbage Collection

Garbage Collection

Garbage Collection = Object Promotion (Copy phase) + Marking (Compact MArk and Sweep) for collection

In JDK 6 there are three types of garbage collectors:

Serial Collector - Single Threaded. 

Entire Garbage collection is done in one thread. Its suitable in 1 cpu machine.
Garbage Collections throughput in a multi-cpu machine is very low. 

Parallel Collector - Garbage Collection is multi-threaded. You can specify the number of threads.
Default value is the number of CPUs. Improves the GC times and throughput as compared to a Serial collector in a multi-cpu machine.

The idea is the Application is completely halted when GC is running. This is stop-the-world-garbage collector

Use this when your app can afford to pause for high times. This will allow the Application to give more throughput. This may not give lowest latency but gives highest throughput since cpu is available 100% until GC.


CMS Collector - Garbage Collection is multi-threaded. You can specify the number of threads.
Default value is the number of CPUs. Improves the GC times and throughput as compared to a Serial collector in a multi-cpu machine.

Concurrent Mark and Sweep. - mark phase and sweep phase.

The idea is this runs concurrently with the app. Mark phase uses very less cpu.

Sweep phase is the time consuming. 

Use this when your app wants low latency and cannot afford big pauses or no down-times or very low to 0 response times are needed from the app.

This will not give highest throughput since since cpu is also engaged in the concurrent GC threads.

Java Heap

Young Gen                              |			Old Gen (Perm Gen)
Eden	Survivor 1	Survivor 2   |

Objects are first allocated on the Eden space. They are promoted from Eden space to S1 then to S2 and then to Old Gen.

Eden -> S1 
This is relatively very fast. There is no real promotion?

Young Gen => Old Gen when there is no allocation space left on Young.
When Old Gen is full and cannot allocate space for objects to be promoted from
Young a Major GC is called.

Major GC = involves object destruction (finalize calls) and memory compaction (arranging the live objects contiguously)

Minor GC = Object Promotion

Young Gen is for allocating the newly created objects.

Young Gen:Old Gen ratio can be specified to the JVM.

Ideally, if you know the behavior of the app then you can determine the objects that are created throughout the life cycle of the app. The ones that live longer or through the life of the app
for e.g. caches etc. the Old Gen should be atleast large enough to accommodate them.  For the other transient objects that come and go through the life of the app Knowing their creation behavior and the pattern of how long they live - you can determine how to divide the rest of the space between Young and Old Gen. The goal is to reduce the chances of Major GC calls as much as possible.


Java Heap = Linkedlist of LinkedLists (Object graph limited by Max Heap Size)

Heap Size : Usually Min and Max heap size should be same.


Let the jvm use the entire address space ( requested on startup for the jvm). This will reduce the number of major GC calls initially (when more memory is needed).

Using a smaller Min Heap size will progressively reduce the number of GC calls as the memory requirement grows in size. But the gc calls will be done often initially until all the memory is being used. 

Java utilities : 

jstack -l <pid>

This C:\>jstack
Usage:
    jstack [-l] <pid>
        (to connect to running process)

Options:
    -l  long listing. Prints additional information about locks
    -h or -help to print this help message

C:\>jstack -l 292
2012-03-03 17:44:00
Full thread dump Java HotSpot(TM) Client VM (11.0-b15 mixed mode):

"Worker-138" prio=6 tid=0x35c82800 nid=0xb44 in Object.wait() [0x3b1cf000..0x3b1cfb94]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185)
        - locked <0x05e10958> (a org.eclipse.core.internal.jobs.WorkerPool)
        at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:217)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51)

   Locked ownable synchronizers:
        - None

jmap


C:\>jmap
Usage:
    jmap -histo <pid>
      (to connect to running process and print histogram of java object heap
    jmap -dump:<dump-options> <pid>
      (to connect to running process and dump java heap)

    dump-options:
      format=b     binary default
      file=<file>  dump heap to <file>

    Example:       jmap -dump:format=b,file=heap.bin <pid>




 num     #instances         #bytes  class name
----------------------------------------------
   1:        726659       78478288  [C
   2:        203312       28493696  <constMethodKlass>
   3:        203312       16281656  <methodKlass>
   4:        660949       15862776  java.lang.String
   5:        328106       15829632  <symbolKlass>
   6:         19521       11986408  <constantPoolKlass>
   7:         19521        9057120  <instanceKlassKlass>
   8:        105091        7067848  [Ljava.lang.Object;
   9:         15915        6887008  <constantPoolCacheKlass>
  10:        195449        4690776  java.util.HashMap$Entry
  11:         23940        4615512  [B
  12:         92234        3980584  [I
  13:         16914        3962112  [Ljava.util.HashMap$Entry;
  14:         51871        3319744  org.eclipse.core.internal.resources.ResourceInfo
  15:         28072        2268280  [S
  16:         20896        2006016  java.lang.Class
  17:         31469        1386112  [[I
  18:         17051        1229088  [[C
  19:         46687        1120488  org.eclipse.core.internal.dtree.DataTreeNode
  20:         28311         992120  [Ljava.lang.String;
  21:         38133         915192  java.util.ArrayList
  22:         27462         659088  org.eclipse.jface.text.Line
  23:         41049         656784  org.eclipse.datatools.sqltools.result.ResultSetRow
  24:         38136         610176  java.lang.Integer
  25:         14605         584200  java.util.HashMap
  26:         12023         577104  org.eclipse.jdt.core.dom.SimpleName
  27:         11607         464280  org.eclipse.ui.internal.navigator.extensions.EvalutationReference
  28:         13974         447168  java.lang.ref.SoftReference
  29:         10908         436320  org.eclipse.jdt.internal.compiler.ast.SingleTypeReference
  30:          3882         434784  org.eclipse.swt.graphics.TextLayout$StyleItem
  31:          1346         430720  <objArrayKlassKlass>



http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html

http://www.javacodegeeks.com/2012/01/practical-garbage-collection-part-1.html

https://weblogs.java.net/blog/2006/05/04/understanding-weak-references