Design Pattern – “An Object Oriented Designer thinking kit”

Life without it - like constructing your dream house without any layout and
realizing the problems in middle or after construction.

Life with it – now you have a layout on which you worked a lot before actual
construction, e.g. proper spaces for ventilation, future expendation, vastu
compliant, parking, entertaining guests, security systems and many more.

The whole idea behind design patterns is to develop a standardized way to represent general solutions to commonly encountered problems in software development.

Direct Benefits –
Biggest Benefit - Easily expandable and reusable structure.
Minimize testing Cost - Changes lead less overhead for re testing.
OOPs – All benefits of being object oriented

Indirect Benefits
Effective way to share experience, over time, we can build up catalogs of patterns. This enables
newcomers to software development to more effectively benefit from experience gained over the years.
There is formal documentation about the tradeoffs involved in software design decisions; about the pluses and minuses of development choices. Standardizing patterns makes it easier for all development professionals—beginners and experts alike—to explicitly understand the implications of their decisions.
The design patterns provide a common vocabulary. This makes communicating decisions to developers easier. Rather than describing a design in detail, we can use a pattern name to explain our plans.

Pattern Best Contributor - “Gang of Four” or GoF
1. Erich Gamma
2. Richard Helm
3. Ralph Johnson
4. John Vlissides

• Design Patterns
  Creational
  Abstract Factory
  Builder
  Factory Method
  Prototype
  Singleton
  <>
  Behavioral
  Observer
  Chain of Responsibility
  Command
  Interpreter
  Iterator
  Mediator
  Memento
  State
  Strategy
  Visitor
  Template Method
  <>
  Structural
  Adapter
  Bridge
  Composite
  Decorator
  Facade
  Flyweight
  Proxy
  <>
  System
  MVC
  Session
  Worker Thread
  Callback
  Successive Update
  Transaction
  <>

if you feel you design a problem with your own way and that way can be useful for others then blog and patent your "Design Pattern".

sumit

Puzzle for brain exercise

five pirates have 100 gold coins. they have to divide up the loot. in order of seniority (suppose pirate 5 is most senior, pirate 1 is least senior), the most senior pirate proposes a distribution of the loot. they vote and if at least 50% accept the proposal, the loot is divided as proposed. otherwise the most senior pirate is executed, and they start over again with the next senior pirate. what solution does the most senior pirate propose? assume they are very intelligent and extremely greedy (and that they would prefer not to die).

Transaction isolation

Transaction isolation (the "I" in ACID) is a critical part of any transactional system.

Transaction isolation is defined in terms of isolation conditions called dirty reads, non repeatable reads, and phantom reads . These conditions describe what can happen when two or more transactions operate on the same data.

A dirty read occurs when the first transaction reads uncommitted changes made by a second transaction. If the second transaction is rolled back, the data read by the first transaction becomes invalid because the rollback undoes the changes. The first transaction won't be aware that the data it has read has become invalid.

A non repeatable read is like one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read").

Phantom reads is like one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.

We can save our application with above un-wanted situations by setting our connection/database isolation level-
1. Read Committed - TRANSACTION_READ_COMMITTED(2) - saves from dirty read
2. Repeatable Read - TRANSACTION_REPEATABLE_READ(4) - saves from dirty and non-repeatable read
3. Serializable - TRANSACTION_SERIALIZABLE(8) - saves from above two and phantom read also.
4. Read Uncommitted - TRANSACTION_READ_UNCOMMITTED(1) - will not save you from any one

we can do these setting either at database end or at application side.

in java application even you can change it dynamically, by conn.setTransactionIsolation(1 or 2 or 4 or 8);

keep one thing in mind higer the lock, will lower the performance. so wisely decide the Isolation level for your application.

if any doubt blog me.

regards,
sumit agarwal