Mastering EJB 3rd Edition - FUD about Spring?

[azzoti]

These comments relate to the downloadable pdf of Mastering EJB 3rd Edition on theServerSide

A couple of points struck me as either plain wrong or misinformation about Spring.

p 270
The section on Distributed Transactions indicates that EJB distributed transaction are more powerful/evolved than Spring plus POJO distributed transactions. Isn't it true that Spring can easily use the JTA API supplied by any J2EE container and thus support distributed transactions in the identical way that EJB supports distributed transactions?

p 272
“For instance, if distributed transactions are a must for your application, Spring + POJO would not work”
This is just just FUD isn't it? All you need is Spring + POJO in any J2EE application server e.g. Tomcat 4.x or Weblogic Express or any full blown EJB capable app server? The application server just has to provide the JTA support as required by the J2EE spec?

p 577
“Note: Remember that we recommend that you always keep the option of scaling your systems up, so when choosing the collocated approach, you should be prepared to switch to a distributed architecture when it becomes necessary.”
(This is not purely a Spring issue, although if valid it would be a strong argument against using Spring.) The implication seems to be that the only way to scale up is to distribute. Surely a collocated application can be scaled up more simply and almost always more effectively using more clustered servers running the duplicated colocated application and an appropriate load balancer?. I.E. NOT Distributing.

[katentim]

“For instance, if distributed transactions are a must for your application, Spring + POJO would not work”
This is just just FUD isn't it?

Yes, that's FUD.

All you need is Spring + POJO in any J2EE application server e.g. Tomcat 4.x

You'll need an app. server supporting JTA. With Tomcat you can use JOTM (although JOTM is not supposed to be as robust - if anyone knows if this has changed, speak up).

when choosing the collocated approach, you should be prepared to switch to a distributed architecture when it becomes necessary.

From FUD to bad design decisions. Such a switch isn't trivial, and would probably be a result of an earlier mistake in the understanding of the architectural needs. Choosing a distributed architecture shouldn't be based on scalability - it will perform worse than co-located. You may have architectural requirements that force you into a distributed architecture however.

Surely a collocated application can be scaled up more simply and almost always more effectively using more clustered servers running the duplicated colocated application and an appropriate load balancer?. I.E. NOT Distributing.

Well apparently not. Is there a emoticon than represents sarcasm.

See Chapter 1 of "Expert One-On-One J2EE Design and Development" for an excellent discussion of this.

[katentim]

Another Gem, this time on AOP, inlcuding Spring's implementation...

You are embedding AOP in your application at the risk of losing portability

Spring's AOP is pure Java. It's as portable as Java. The same can't be said of EJBs.

[azzoti]

Thanks for the reply katentim.

I was just reading about JOTM in "j2ee without ejb" but I just spotted this in the Tomcat documentation at http://jakarta.apache.org/tomcat/tom...les-howto.html

"Tomcat 4.1 provides transaction management and resource configuration support through the use of Tyrex 1.0. This allows the user to obtain JTA/JCA resources from the JNDI namespace, as well as the standard javax.transaction.UserTransaction."

juergen h started a thread (jul 2002) about tomcat+tyrex at http://www.caucho.com/support/resin-...0207/0628.html where he seems to have used the tyrex+tomcat combination for distributed transactions.

[Tomcat+tyrex is an aside. From what I understand, and contrary to the "Mastering EJB 3rd ed" FUD, Spring will work fine with POJOs and distributed transactions using a $$$ app server to provide the JTA services. ]

[katentim]

“For instance, if distributed transactions are a must for your application, Spring + POJO would not work”
This is just just FUD isn't it?

Yes, that's FUD.

Seems like they've finally acknowledged this in the 4th edition.
Mastering EJB 4th edition - "...frameworks such as Spring and Hibernate do support distributed transactions..."

[ronaldtm]

eh? How do you propagate transactions to clients (swing apps, for example) when you do remote calls?

[Colin Yates]

I believe (although I am just looking into this myself) that you need to use JTA and only if the server side supports it.

If you are making multiple EJB calls then again using a JTADataSource will allow the transaction context to be passed back to the EJB server and they should all work as expected.

I don't think that Spring will support the mixing of local and remote transactions though, so if you start a transaction locally and then call a remote EJB I don't think that remote EJB can access that initial transaction...maybe if they are both using JTA????

The other point I really think you need to consider is that generally transactions need to be as small as possible and if possible you should avoid passing the transaction around....having the client start a transaction, call a remote service and then end the transaction could end up with all kinds of pain. Typically the remote call is where the transactional layer lives, i.e. the transaction is purely on the remote end.

Like I said, take all of this with the *biggest* grain of salt you can find

[wqtspring]

p 270
The section on Distributed Transactions indicates that EJB distributed transaction are more powerful/evolved than Spring plus POJO distributed transactions. Isn't it true that Spring can easily use the JTA API supplied by any J2EE container and thus support distributed transactions in the identical way that EJB supports distributed transactions?

From the Spring PDF doc:

Spring does not support propagation of transaction contexts across remote calls, as do high-end application
servers. If you need this feature, we recommend that you use EJB. However, don't use this feature lightly.
Normally we don't want transactions to span remote calls.

[katentim]

Mastering EJB 4th edition - "...frameworks such as Spring and Hibernate do support distributed transactions..."

How do you propagate transactions to clients

It is referring to distributed across databases (e.g. using JTA).