Hibernate, an open source, high performance persistence and query service, is a key component of JBoss. According to Gavin King, founder and leader of the Hibernate project, Hibernate3's compatibility with EJB3 allows pluggability between persistence vendors, ORM vendors and the EJB3 container. In this tech talk King discusses how Hibernate3 builds upon and extends EJB3, addressing such topics as:

- New features of Hibernate3
- The relationship between Hibernate3 and the EJB3 container in JBoss
- What differentiates Hibernate3 from the EJB3 specification
- Hibernate's custom annotations available outside EJB
- The future of Hibernate

Watch Gavin King on Hibernate3 and EJB3.

I'll add the obligitory post requesting that interview postings be accompanied by a date as to when the interview was conducted. This one seems ancient if Gavin is just introducing the new features of Hibernate 3!

If you are looking for an interview with Gavin that was conducted this decade, you can save time by going here.

I agree with Corby. The Javaposse interview is really great. I heard it a few days ago and I especially liked that part when Gavin discusses "put everything in the http session" vs. Stateful Session Beans.

I agree with Corby. The Javaposse interview is really great. I heard it a few days ago and I especially liked that part when Gavin discusses "put everything in the http session" vs. Stateful Session Beans.

+1. Seeing people point and laugh mindlessly while shouting the words "Non-scalable" whenever Stateful SBs are even slightly mentioned always amuzes me. Once they stop and I ask them why and what experience they have that made them think that way, its always (for me anyway) the "because its a known fact!" reply. Poor souls.

Can someone please explain the specific benefits of stateful session beans for the use cases that Gavin is describing? (Seam-related, I assume.)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Can someone please explain the specific benefits of stateful session beans for the use cases that Gavin is describing?

The alternative to a SFSB is to put a JavaBean in the HttpSession. There are two problems with this:

(1) HttpSession contract does not have dirty checking, so this approach tends to break in a custered environment (yes, I realize that Coherence provides dirty checking, as does JBoss HttpSession implementation, but this is definitely nonstandard). The only way to make it work in a standard way is to re-set the attribute each time you change the bean state, which is extremely bug-prone and difficult to test.

(2) A JavaBean does not have things like transaction demarcation on its method calls, so you would have to either pass the JavaBean object to a SLSB to do your business logic (very non-OO) or basically reimplement the functionality that is already provided by SFSBs if you wanted to add the business logic to the bean.

In practice, in J2EE, people waste enormous amounts of code passing state to and from the HttpSession and the SFSB. This is totally crazy, since J2EE already provides a construct that saves you all this work.

(having troubles posting ..)

(1) HttpSession contract does not have dirty checking, so this approach tends to break in a custered environment (yes, I realize that Coherence provides dirty checking, as does JBoss HttpSession implementation, but this is definitely nonstandard). The only way to make it work in a standard way is to re-set the attribute each time you change the bean state, which is extremely bug-prone and difficult to test.

(2) A JavaBean does not have things like transaction demarcation on its method calls, so you would have to either pass the JavaBean object to a SLSB to do your business logic (very non-OO) or basically reimplement the functionality that is already provided by SFSBs if you wanted to add the business logic to the bean.

So I assume you would store the ref and/or handle to the SfSB in the HTTP session, and do the life cycle management on the SfSB in concert with the events from the HTTP session?

Also, can you refresh my memory on SfSBs, is their state (i.e. the contents of their fields) transactional, so if the EJB transaction rolls back so do their fields?

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

]So I assume you would store the ref and/or handle to the SfSB in the HTTP session, and do the life cycle management on the SfSB in concert with the events from the HTTP session?Also, can you refresh my memory on SfSBs, is their state (i.e. the contents of their fields) transactional, so if the EJB transaction rolls back so do their fields?

You could store the reference in the HttpSession or in the client. In Seam there is a simple switch to choose between the two options. HttpSession in the default and most likely choice for most applications.

No, SFSB state is not transactional.

You could store the reference in the HttpSession or in the client. In Seam there is a simple switch to choose between the two options. HttpSession in the default and most likely choice for most applications.No, SFSB state is not transactional.

You used to be able to implement an interface, something like "TransactionSynchronization something something" that would give you callbacks so you could at least KNOW if the SfSB state was modified in a transaction and what the outcome of the transaction was, so you could code compensating transaction code. Is that still there?

Anyway, I agree that we need to kill the idea that apps are stateless, 'cause it's never been true. For me, though, I'll stick with the new session and request scoped components in Spring 2, since they let me wire things together at a finer-grained level than even EJB3.

Can someone please explain the specific benefits of stateful session beans for the use cases that Gavin is describing?

The alternative to a SFSB is to put a JavaBean in the HttpSession. There are two problems with this:(1) HttpSession contract does not have dirty checking, so this approach tends to break in a custered environment (yes, I realize that Coherence provides dirty checking, as does JBoss HttpSession implementation, but this is definitely nonstandard). The only way to make it work in a standard way is to re-set the attribute each time you change the bean state, which is extremely bug-prone and difficult to test.(2) A JavaBean does not have things like transaction demarcation on its method calls, so you would have to either pass the JavaBean object to a SLSB to do your business logic (very non-OO) or basically reimplement the functionality that is already provided by SFSBs if you wanted to add the business logic to the bean.In practice, in J2EE, people waste enormous amounts of code passing state to and from the HttpSession and the SFSB. This is totally crazy, since J2EE already provides a construct that saves you all this work.

Does SF S EJB3 offer "pasivation"? It was a nice feature to avoid "OutOfMemory" if you have too much sessions ...

I agree with Corby. The Javaposse interview is really great. I heard it a few days ago and I especially liked that part when Gavin discusses "put everything in the http session" vs. Stateful Session Beans.

+1. Seeing people point and laugh mindlessly while shouting the words "Non-scalable" whenever Stateful SBs are even slightly mentioned always amuzes me. Once they stop and I ask them why and what experience they have that made them think that way, its always (for me anyway) the "because its a known fact!" reply. Poor souls.

How so? As the saying goes, I don't have to stick my hand into fire to prove to myself that it burns. Why not learn from others instead of repeating the same mistakes. I worked, for example, with entity beans using EJB 1.1 and they sucked. They weren't particularly portable, they were slow, and it was impossible to use a true object model and oh yeah, forget about using the same object outside of the container.

Now, I *know* they suck from direct experience. Everywhere I read of people saying entity beans sucked said that stateful session beans had problems.

Do I need to devote 5 months of time creating a project that didn't work well, pissing off customers, injuring my company or do I put my hand to my ear and listen and dodge the bullet?

I say don't get shot.

Dont know about entities in 1.1, but i've personally used them in 2.0 and they don't "suck" as much as all the noise thats floating around seem to imply, provided you use them correctly and appropriately. Its the same deal with stateful AND stateless beans. In fact my experience so far has been that, whenver things doesn't scale or go wrong, the so called "architects" will always blame the framework first and foremost, then point at the noise if any. In fact, I've seen an architecture that uses solely stateless beans and it still doesn't scale, does that mean stateless beans are not scalable?

Entity beans are tricky to use, in terms usefulless in the idiotic scale (as in you really have to know how and when to use it), sure it sucks. But as far as performance and scalability wise, when using it correctly and in the right places, no, I don't believe it "sucks".

I agree with Corby. The Javaposse interview is really great. I heard it a few days ago and I especially liked that part when Gavin discusses "put everything in the http session" vs. Stateful Session Beans.

+1. Seeing people point and laugh mindlessly while shouting the words "Non-scalable" whenever Stateful SBs are even slightly mentioned always amuzes me. Once they stop and I ask them why and what experience they have that made them think that way, its always (for me anyway) the "because its a known fact!" reply. Poor souls.

How so? As the saying goes, I don't have to stick my hand into fire to prove to myself that it burns. Why not learn from others instead of repeating the same mistakes. I worked, for example, with entity beans using EJB 1.1 and they sucked. They weren't particularly portable, they were slow, and it was impossible to use a true object model and oh yeah, forget about using the same object outside of the container.Now, I *know* they suck from direct experience. Everywhere I read of people saying entity beans sucked said that stateful session beans had problems.Do I need to devote 5 months of time creating a project that didn't work well, pissing off customers, injuring my company or do I put my hand to my ear and listen and dodge the bullet?I say don't get shot.

Sorry forgot to quote the message i was replying to...

Dont know about entities in 1.1, but i've personally used them in 2.0 and they don't "suck" as much as all the noise thats floating around seem to imply, provided you use them correctly and appropriately. Its the same deal with stateful AND stateless beans. In fact my experience so far has been that, whenver things doesn't scale or go wrong, the so called "architects" will always blame the framework first and foremost, then point at the noise if any. In fact, I've seen an architecture that uses solely stateless beans and it still doesn't scale, does that mean stateless beans are not scalable?

Entity beans are tricky to use, in terms usefulless in the idiotic scale (as in you really have to know how and when to use it), sure it sucks. But as far as performance and scalability wise, when using it correctly and in the right places, no, I don't believe it "sucks".

Entity beans are tricky to use, in terms usefulless in the idiotic scale (as in you really have to know how and when to use it), sure it sucks. But as far as performance and scalability wise, when using it correctly and in the right places, no, I don't believe it "sucks".

BEA EJB21 CMPs were tuned in the way they were faster than Hibernate 2 ...

I agree with Corby. The Javaposse interview is really great. I heard it a few days ago and I especially liked that part when Gavin discusses "put everything in the http session" vs. Stateful Session Beans.

+1. Seeing people point and laugh mindlessly while shouting the words "Non-scalable" whenever Stateful SBs are even slightly mentioned always amuzes me. Once they stop and I ask them why and what experience they have that made them think that way, its always (for me anyway) the "because its a known fact!" reply. Poor souls.

Ok, so to turn it back around on you, can you explain why using the Http session is worse than using SSBs?

Ok, so to turn it back around on you, can you explain why using the Http session is worse than using SSBs?

I am assuming that something turned out to be easy (or easier) or slick (or slicker) to do with SfSBs, which is great, but I'm just trying to figure out what it was the SfSBs did well that made them compelling in this case.

I figure it's either something handy about SfSBs in general, or it's something that jboss does with SfSBs that made some other capability easier. Either way, a simple explanation would do.

I'm a bit surprised that no one has popped up with the slightest hint of technical detail to respond.

As far as scalability goes, there should be little to no difference between HTTP sessions and SfSBs, other than differences in an implementation regardling the various QoS that it provides for each. What most people complained about regarding scalability was actually the number of SfSB instances on a single server (i.e. they do take _some_ memory), not horizontal scalability. For example, in a web app without redundancy for failover, you can manage an infinite number of SfSBs with linear scalability just by adding more servers. (You can even achieve the same with redundancy for failover, assuming the clustering is half decent. Most of the early implementations of SfSB clustering relied on multicast, which is shite for scalability.)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

I agree with Corby. The Javaposse interview is really great. I heard it a few days ago and I especially liked that part when Gavin discusses "put everything in the http session" vs. Stateful Session Beans.

+1. Seeing people point and laugh mindlessly while shouting the words "Non-scalable" whenever Stateful SBs are even slightly mentioned always amuzes me. Once they stop and I ask them why and what experience they have that made them think that way, its always (for me anyway) the "because its a known fact!" reply. Poor souls.

Ok, so to turn it back around on you, can you explain why using the Http session is worse than using SSBs?

I wouldn't hold the holy grail and say that Http session are worst than SFSBs, nor the other way around (as my post pointed out, all I see is people doing exactly that in regards to SFSB being worst off than Http Sessions).

Here's an example of where I think HttpSessions are being misused (sorry I cannot go into more detail). I was task with maintainig a system where the design is such that there are SLSBs performing business processing for a client requests, but the client state is stored in the HttpSession. However, the state data that is being put into the session is huge (think Collections of javabeans within collections within collections). The servlet/jsp really only need a small part of that data to render the view for the user. The user will fill out the view, post back to the servlet/jsp, which in turn extract the state from the session and tags the user-requests into it, then calls the SLSB and pass back the state (the whole thing) to it.

See the problem here? the servlet/jsp only really needs a small part of the state to render the appropriate view, yet it has the whole state in the HttpSession because that is the only place it can hold the state, the SLSB sure isn't going to hold it, and putting it in the DB for every request is even worst. Then for every user-request, we pass the whole thing back to the SLSB, the SLSB does the processing, update the state and send back the state to the servlet/jsp which updates the session, back-and-forth, back-and-forth for the entire client session. Now if the web layer is deployed in another network segment or on another VM, then we have the servlet/jsp serializing this huge state object to the SLSB on every request then you have a performance problem.

Now, in this scenario why can't we have SFSBs hold the state, pass only the necessary info needed by the servlet/jsp to render its view and only have the the request data from the user interaction passed back? We don't need to pass the whole state when the web layer only needs a small part of it for generating the view.

So I tried to do a transcript of that passage in question. I hope I didn't make too many mistake while transcribing it. (You know Gavin is a real quick speaker and I am just an average quick typer and in addition english is not my mother tongue so there might also be some mis-hearings. So take it with a grain of salt.)

An approximation of what he said it the following:

... The other thing we wanna do is get away from this idea of stateless architectures.... This is ancient canard in the Java community that is that stateful session beans are unscalable. People have heard this so many times... I mean it has been around for years and years and years... I think the reason it first came about was because WebFooBar 1.0 used to write the stateful session beans' state to the database after each request. So yeah that was unscalable.... So the people go "we put our state in the http session" which is of course ridiculous because the http session is in no way more scalable than a stateful session bean. It is rather a much weaker construct than the stateful session bean is. The other thing they do "ooh ok, then we will write the state to the database at the beginning and at the end of each request" and of course that is even worse because the database is the least scalable tier and of course they discover that and they discover "ooh, that application isn't scaling because of all this database access so what I'm gonna do is introduce a second level cache". So now that application is no longer stateless in fact. Now we have a second level cache where we're keeping our stuff in memory but the thing about second level cache is that second level cache is a much much less scalable construct....
stateful session beans and the http session represent conversational state and conversational state only needs to be replicated to 2 or 3 nodes in the cluster. whereas the second cache needs to be kept consistent across the whole cluster and consistent with the database wich is a very very expensive thing to ensure.

I should add that the above transcript is a partial transcript of the javaposse interview not of theserverside interview.

If you are looking for an interview with Gavin that was conducted this decade, you can save time by going here.

Good call. Thanks. This Java Posse is a very good interview. Gavin talks about Hibernate, Seam and gives his opinion on JSF (even JSF vs. Hibernate).

If you are looking for an interview with Gavin that was conducted this decade, you can save time by going here.

Good call. Thanks. This Java Posse is a very good interview. Gavin talks about Hibernate, Seam and gives his opinion on JSF (even JSF vs. Hibernate).

I meant JSF vs. Tapestry.

If you are looking for an interview with Gavin that was conducted this decade, you can save time by going here.

Turns out Gavin King is a big JSF fan according to the JavaPosse interview.

You might say Gavin seems to really dig JSF (pun intended). Here is a transcript from his JavaPosse interview when asked about JSF.

(I was listening to JavaPosse, which is a fairly neat site. Thanks)

Dick Wall from Java Posses asks Gavin King:

"What are the strong points of JSF?"

Gavin King:
"The rough ride JSF has been getting has been vastly exagerated. We can see a lot of adoption of JSF. Along with some noisy people who are promoting competing frameworks in fact. One of the things you need to when you need to see a technology that is really going to take off is to look how many people are screaming about it and saying how terrible it is. That is the case with Hibernate. It was the case wtih EJB3. It is the case with the organization I work for. You know there are number of people in the industry who are great negative indicators. When they hate something you know its real. And JSF is one of those things."

"JSF is a fantastic model. It is very easy to use. Most of the critisim that is made of JSF is actually factually incorect. On these community sites that claim you can't build restful application with JSF. I mean it is total nonsense. It is not even remotely true."

"When I came to look at JSF, I was casting around for a web framework to marry with EJB3. I was looking around and I was 'well let's start with what it is the spec. (JSF)'. And I was thinking it was going to be a steaming pile. (However), I found once I actually sat down and looked at it. It was working how I would think to design a (web) framework. When I used it, it was real easy to use and I think it is great."

...

You can read more of this transcript at:
http://jroller.com/page/RickHigh?entry=turns_out_gavin_king_is

Check out the complete interview at:
http://www.javaposse.com/index.php?post_id=59304

I'll add the obligitory post requesting that interview postings be accompanied by a date as to when the interview was conducted. This one seems ancient if Gavin is just introducing the new features of Hibernate 3!

According to the Hibernate website, the EntityManager (key API of EJB3 for Hibernate) is still in Beta. Beta 8 to be exact.

When is Spring going to support EJB3 (ala the EntityManager API)?

I am listening to the interview now. I wish they could have worked in a few questions about Seam.

When is Spring going to support EJB3 (ala the EntityManager API)?

It's been in there since 2.0M2 [see CVS]...

When is Spring going to support EJB3 (ala the EntityManager API)?

It's been in there since 2.0M2 [see CVS]...

Cool. I was looking at the 2.0 documentation not the source code. It is not discussed in the documents yet.

Good to know that it is there.

I use the Criteria API a bit. There seems to be no equiv. in EJB3. I am still not sure why I would want to use the EJB3 API over the normal Hibernate API (given that we use the Criteria API quite a bit).

The documentation isn't entirely in synch with the current codebase. We still have work to do in that area before the Spring 2.0 final release.

A link to a presentation by Thomas Risberg that discusses the JPA in more detail is included below.

regards,
Alef

http://springdeveloper.com/psug/psug-new-persistence.pdf

When is Spring going to support EJB3 (ala the EntityManager API)?

It's been in there since 2.0M2 [see CVS]...

Cool. I was looking at the 2.0 documentation not the source code. It is not discussed in the documents yet.Good to know that it is there.I use the Criteria API a bit. There seems to be no equiv. in EJB3. I am still not sure why I would want to use the EJB3 API over the normal Hibernate API (given that we use the Criteria API quite a bit).

Yeah, I pretty much stick to the Criteria API since it's extremely easy to write adaptors to other system (such as a PageModel that works with the Criteria API). I suppose you could switch to a StringBuffer to build the criteria...

I second this.

What is the rationale/reason for TSS _not_ to state the dates of these interviews? This is regularly frustrating.

John Hurst
Wellington, New Zealand

Hibernate, an open source, high performance persistence and query service, is a key component of JBoss. According to Gavin King, founder and leader of the Hibernate project, Hibernate3's compatibility with EJB3 allows pluggability between persistence vendors, ORM vendors and the EJB3 container. In this tech talk King discusses how Hibernate3 builds upon and extends EJB3, addressing such topics as:- New features of Hibernate3- The relationship between Hibernate3 and the EJB3 container in JBoss- What differentiates Hibernate3 from the EJB3 specification- Hibernate's custom annotations available outside EJB- The future of HibernateWatch Gavin King on Hibernate3 and EJB3.

This does seem old. Gavin says that in a month or so they are going to release Hibernate 3.1. Hmmm... Hibernate 3.1.2 is already released.

The date of the 3.1 download is Decemenber 2005 so this must have been done last November or so.

Ups, just back from vacation.

Yes, this interview was recorded at TSSS last year, so almost a year old now.

I want to aplogise to Joshua Davis for not dropping his name in the interview, when I was talking about the now-not-so-new query translator stuff that he designed and implemented.

I have tried watching this interview, but gave up in frustration.

Firstly, real player did not install in Firefox. I had to download and install it separately before it would play.

Once I got it playing the interview would play for maybe 30 seconds before halting to download another segment. The breaks were in the middle of sentences so it was rather difficult to follow everything.