jolbox.com

Let’s start off with some sample code. The following sample will throw an error at runtime. Can you identify the problem?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

@Autowired 
SomeClass someClass;
 
public void doSomething(){ 
	someClass.callFoo(); 
} 
 
@Component
public class SomeClass{ 
	public void callFoo() { 
		writeToDB(); 
       }
}	
 
@Transactional 
public void writeToDB(){
 // write to the db here 
}

Before we discuss the problem, let’s go back to the basics on some aspects of Spring for a tiny refresher:

1
2
3
4
5
6
7

@Component
public class Foo { … }
 
public class somewhereElse{ 
	@Autowired
	Foo fooBar;     
}

The @Autowired annotation in line 5 tells Spring to fill in the variable “fooBar” just as if you wrote fooBar = new Foo(). Now the key thing here is this: you’re asking someone else (Spring) to give you what is required. In other words, you have given the Spring library the chance to do something before giving you what you asked for.

Now back to our initial example. In line 5, reproduced below:

1

	someClass.callFoo();

the variable someClass was obtained via Spring (via the @Autowired annotation); therefore you need to read this line as :

1

	[something Spring gave you].callFoo();

So far so good. Tracing through the code we now arrive at the writeToDB call:

1
2
3

	public void callFoo() { 
		writeToDB(); 
       }

this time there is no Spring involved! Even though you initially jumped to the class via the spring handle, at this point you’re simply jumping from one method to the next just as if you typed this.writeToDB().

Put differently, you are now back to “normal” Java land, no Spring library or proxy involved here! Some people think that once you’ve jumped into the class via Spring, the Spring Framework is still somehow in control. This is not the case! Spring has done it’s job and is now gone!

With this in mind, it should be obvious that the @Transactional will have no effect whatsoever because there’s no place where anyone is checking for it, thus leading to a “no session bound to thread” error the moment you try to write to the database.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

@Autowired 
SomeClass someClass;
 
public void doSomething(){ 
	someClass.callFoo();  <-- someClass is a proxy, Spring can kick in
} 
 
@Component
public class SomeClass{ 
	public void callFoo() { 
		writeToDB();    <-- No spring here. You’re back in normal Java land
       }
}	
 
@Transactional                 <-- Java ignores this
public void writeToDB(){
  write to the db here         <-- "No session bound to thread here"
}

Now let’s make a little change by moving the @Transactional attribute elsewhere.

Remember the [something Spring gave you].callFoo() call? This time, Spring gets a change to see the @Transactional annotation because before jumping to the method callFoo(), it can perform the @Transactional magic.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@Autowired 
SomeClass someClass;
 
public void doSomething(){ 
	someClass.callFoo(); 	<-- someClass is a proxy, Spring can kick in 
} 
 
@Component
public class SomeClass{ 
 
       @Transactional		<-- Spring sees this, starts session context
	public void callFoo() { 
		writeToDB(); 		
}	
 
 
public void writeToDB(){
	  write to the db here   <-- Now it works
}

Now for some rules of the game:

• Decide once and for all who’s going to define the @Transactional. Don’t sprinkle these around! The sensible place where to place these is in the service layer. If you add the annotation on your data layer you will probably be creating transactions all over the place!
• new XXX() is a potential source of trouble. @Autowired/getBean() are your friends

JolBox is home to BoneCP – the fast JDBC Connection Pool