Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
Showing posts with label Spring. Show all posts
Showing posts with label Spring. Show all posts

Tuesday, June 17, 2008

Transaction Attributes in Spring

In spring, Transaction attribute defines the rules for applying policies on methods. It can have one or more parameters from the following:
1. Propagation behavior
2. Isolation level
3. Read only hints
4. Transaction timeout period

Propagation behavior is used to define the transaction boundaries.. Its very much inherited from EJBs transaction management. ADF Bounded task flow do have similar stuff. Spring has a much richer set of propagation behavior managment compare to EJBs. In brief these are:

a)PROPAGATION_MANDATORY: signifies method must be running in a transaction
b)PROPAGATION_NESTED: this is not in EJBs. It talks about creating a new child transaction if a transaction is already existing.
c)PROPAGATION_NEVER: signifies that method should not be running in a transactional context.
d)PROPAGATION_NOT_SUPPORTED: same as above but above will throw exception in case it happens. This will suspend the transaction for the duration the method runs.
e)PROPAGATION_REQUIRED: there must be a transactional context present if not there it will create a new.
f)PROPAGATION_REQUIRES_NEW: there should not be any pre-existing transactional context. it will create a new.
g)PROPAGATION_SUPPORTS: it signifies that it does not need a transactional context but if there is any it doesnt mind.

Isolation level:
This has something to do with the concurrency control. When multiple transactions are running they may cause dirty reads, non repeateable reads and phantom reads. Spring provides various options depending upon the tolerance of the business use case you can use one. these are:
a)ISOLATION_DEFAULT: it uses the undelying datastore isolation policy.
b) ISOLATION_READ_UNCOMMITTED: it allows to read the data even when there are uncommited rows thus could lead dirty read or non repeateable read or phantom reads.
c) ISOLATION_READ_COMMITTED: only commited rows are read but still it may cause non-repeateable read or phantom reads.
d) ISOLATION_REPEATABLE_READ: as name suggests prevents dirty read as well as non-repeateable issues but phantom reads could be there.
e)ISOLATION_SERIALIZABLE: this brings the ACID (Atomicity, concurrancy, isolation and durability) compliance. But it is very strict and restricted so could be a performace issue.

Read only hints: Sometimes there is a requirement to just read the data from the datastore. in that case providing this attribute can make a good performance boost as datastore can apply some optimizations. But this can be done by datastore when a new transaction started. so this attribute makes sense only if propagation propety is PROPAGATION_REQUIRED, PROPAGATION_REQUIRES_NEW, or PROPAGATION_NESTED.

Transaction Timeout: This is just a way to prevent deadlocks or unresponsive threads or resource locks in the system. You can specify some timeout that will kill the transaction after the specified timeout period. again it starts when a new transaction begins so it makes sense if propagation is PROPAGATION_REQUIRED, PROPAGATION_REQUIRES_NEW, or PROPAGATION_NESTED.

Monday, June 2, 2008

Life cycle of a bean in spring

Spring's bean has a very elaborated life cycle which gives opportunities to hook up some custom code or logic in various life cycle stages. There are two distinct spring containers one is bean factory and another is application context. Life cycle phases varies a lil in the containers. More precisely, only one additional phase is added in case of application context. Let's see what these phases are:

1. Instantiate: in this phase container finds the bean's definition and instantiates it.
2. Populate properties: in this phase using the dependency injection all the properties are populated which are specified in the bean definiton (in the xml file).
3. BeanNameAware: If BeanNameAware interface is implemented the factory calls the setBeanName() passing the Bean's Id.
4. BeanFactoryAware: if BeanFactoryAware interface is implemented setBeanFactory() method is called.
5. ApplicationContextAware: This step is valid only if the Application context container is used. In this phase if bean implements the ApplicationcontextAware then setApplicationContext() method is called.
6. Pre-initialization: If any BeanPostProcessors are associated with the bean then their postProcessBeforeInitialization() methods will be called.
7. InitializingBean: If an init-methodis specified for the bean then it is called.
8. Call custom init-method: If there are any BeanPostProcessors are associated then postProcessAfterInitialization() is called.

Above are the lifecycle phase when a bean becomes ready to use in the container. An existing bean can be removed from the container in two ways:
1. DisposableBean: If bean implements the DisposableBean interface then destroy() method is called.
2. Call-custom destroy: if custom-destroy method is specified then it is called.

Monday, May 26, 2008

Spring modules

Spring has seven well defined modules which collaborates to deliver everything that you may need to build an enterprise application. Lets discuss one by one in brief:

1. The Core Container: This i responsible for providing fundamental services of the Spring framework. It uses powerful Inversion of control (IoC) which i discussed in previous topic to separate the bean configuration and wiring stuff from the core application logic.

2. Application Context: This modules makes spring capable to support internalizations, message handling, application life cycle events etc. It provides a lot of useful and necesaary services like JNDI, email, scheduling, EJB integration and integration with template generator frameworks like Velocity.

3. AOP Module: AOP that is, Aspect oriented programming is supported very well using Spring's AOP module. AOP basically helps in separating the concerns. Unlike EJB style coding days where implementing the business logic involves looking up context (thru jndi) etcs in AOP that part is totally separated out. Using dependency injections required context and beans are avaialble to other beans and thus make the code clean and independent.

4. JDBC and DAO abstraction: Spring instead of re-inventing the wheel provide the hooks to well known and stable ways of doing DB stuff like JDBC, DAO etc. This module in spring hides all the boilerplate code and also provides one more layer to throw exceptions which are more meaningful over SQL type exceptions.

5. OR mapping integration: Object relational mapping tools like hibernate, toplink, JDO etc are supoorted by spring's OR module. Spring does not have any owned ORM solution as already good orm solutions are available.

6. Web module: Web module is bascially build on the top of Application context module. Web modules sets the platform for supporting web applications. This module does the additional tasks like programmatic binding of request objects to the business objects, multipart requests for file upload support etc.

7. MVC framework: Spring provides support to plug-in any popular MVC framework like struts. But advantage of using spring's own MVC framework is the use of Ioc which helps in separating the business layer from the controller logic.

Thursday, May 22, 2008

Inversion of Control

In layman terms "Instead of having dependencies to the enclosing environment, let environment decide on how to react on enclosed program’s actions or events"... The popular phrase is "Don’t call me, I will call you"

Implementation using structured programming languages w/o following the Inversion of Control (IoC) design pattern are fairly simple but had a tight coupling. So, in long run becomes difficult to maintain and thus involves huge investments and overheads...

To understand it better. Say there is an object Car and an object Engine. An user class may implement it as:
Class Engine{...}

Class Car{
private Engine e;
Car(){
e= new Engine();
}
}


The prbolem with the above code is the tight coupling between the engine and the car classes. Say if way to construct an engine object changes then it will require the Car class to be modifed. Now, if we change the code for class Car as:
Class Car{
private Engine e;

Car(Engine e){
this.e = e;
}
}


Now, in this case class Car doesn't need to know that how to create engine object. Invoker of class Car has the responsibility to pass the proper engine instance to class car. This way the control is inverted and is driven by environment that makes the user program much more flexible and loosely coupled...

Spring is one of the popular J2EE framework, which is having an Inversion of Control Container as a very important component (sub-framework). Spring framework heavily uses this principal and thus moves the event or flow management to the framework from the application code. It uses a flavor of IoC called Dependency Injection.

Where, IoC increases tremendous flexibility to the application, it also injects the complexity to the system and makes it pretty less deterministic...

To be continued....