Merging A Detached Object

In an earlier post we saw how to reattach detached objects using update() and lock(). Consider the below code where we try to reattach an object.

public static  void needForMerge() {

get() versus load() - The Battle Continues...

In the previous two posts we saw the behavior of get() and load() methods and how it differed when session caching came into the picture.

get() versus load() - Things Get Murkier

In the previous post we saw the real difference between the load and get methods of the session. We saw that load() works with proxies and get() works with actual database entities.But this behaviour changes completely when the persistence context comes into picture.

get() versus load()

This has to be one of the most popular questions asked in hibernate interviews:
What is the difference between get() and load() method ?
Hibernate provides us with the two methods to load a persistent entity from the database. These signatures are session.get(Class, Serializable) and session.load(Class, Serializable). Both methods take a class variable and an identifier object and return an instance of the Entity class.

From Detached to Removed

In our previous post we saw how to transition a detached object back to a persistent state. Is it possible to delete an entity from the database if it is not associated with any session? Would Hibernate throw an exception or would the delete succeed? Or would the code simply crash ? The best way to be sure is to try it out on our own :

Autowiring By Constructor

In this technique, the Spring Container tries to match up beans in the container with the parameters of the constructor arg while creating the bean. Consider the CarByConstructor class:

Autowiring By Type

In this type of autowiring the Spring Container will attempt to configure the bean properties based on the type of the property. Consider the below ICar implementation:

Autowiring - By Name

In the posts so far we have been defining our beans and configuring them using configuration files. However this results in very large XML files. Spring allows the properties of beans to be automatically wired based on the name of the property or some other conditions.

Injecting Null

In the last posts we saw Springs ability to inject collections - both simple value types and complex object types. But just because Spring allows us to configure objects does not mean we have to always configure them. For e.g. there could be a Singer class that uses constructor injection to wire its "song" property. But what do you do if you don't have a song ?

Injecting Collections of Objects

In the previous post we saw how to inject a collection of values. However Spring is not limited to only wiring primitive values . It allows us to create collections of beans and wire them into other beans as well.

Injecting Value Based Collections

Spring allows us to create beans that are wired with Collections and Arrays. In this post we shall create a simple class that has different collection based properties and then wire them with simple string values.

Injecting Properties Of Beans

Simply creating beans is not the only work of the container. We also need it to able to configure the newly instantiated beans. We need to 'inject dependencies' into these beans. There are two ways to inject the bean properties. One is using

The p namespace

<bean id ="band" class ="com.performer.Band">
    <property name="musician" ref="musician"></property>
    <property name="singer" ref="singer"></property>
</bean>

The above XML fragment