6 Replies Latest reply on Mar 6, 2009 2:13 AM by joblini

Seam withouth EJB3 tradeoffs (discussion from Seam Framework book 2nd edition)

infinity2heaven Mar 5, 2009 4:23 PM

Having worked on a Seam/EJB3 project earlier, I'm recommending Seam to my new client. But the client insists on a non-ejb platform and I haven't worked on it except for running the seam jpa booking example. It seems fine to me until I read this chapter from the book:

Seam Framework - Experience the evolution of Java EE second edition book. Chapter 4 Seam without EJB3 Page 52

Pojo Tradeoffs:

- No support exists for declarative method-level transactions in Pojos, Instead you can configure Seam to demarcate a database transaction from the moment the web request
is received until the response page is rendered

What does this mean? Isn't @Transactional on method level support declarative transactions on pojo? This is a strong statement and can shun away people from adopting Seam

- No transaction or component level persistence context exists. All persistence contexts in Seam Pojos are extended

what does that mean wrt to Seam jpa booking example?

- No Java Remoting (RMI) into Seam Pojo method exists

Does that mean, we can't use GWT?

I'd appreciate any comments from those who developed Seam without EJB3 (production)

1. Re: Seam withouth EJB3 tradeoffs (discussion from Seam Framework book 2nd edition)

swd847 Mar 5, 2009 10:57 PM (in response to infinity2heaven)

- No support exists for declarative method-level transactions in Pojos, Instead you can configure Seam to demarcate a database transaction from the moment the web request is received until the response page is rendered

With EJB3 you can do @TransactionAttribute(REQUIRES_NEW) to demarcate separate transactions per request, seam POJO transaction management does not allow this.

- No transaction or component level persistence context exists. All persistence contexts in Seam Pojos are extended

When using EJB3 you can get a transaction scoped entityManger using @PersistenceContext injection. This is not possible using seam, as the seam managed persistence context is always extended (and usually conversation scoped)
Actions
2. Re: Seam withouth EJB3 tradeoffs (discussion from Seam Framework book 2nd edition)

www.supernovasoftware.com Mar 5, 2009 11:14 PM (in response to infinity2heaven)

I am quite happy with EJB3 over POJO except the following

https://jira.jboss.org/jira/browse/EJBTHREE-1096

This is a productivity killer. This should be resolved in the future, but it is undetermined when.
Actions
3. Re: Seam withouth EJB3 tradeoffs (discussion from Seam Framework book 2nd edition)

infinity2heaven Mar 5, 2009 11:18 PM (in response to infinity2heaven)

@Transactional on Pojos support all the Propagation types. I'm not sure why you say --

With EJB3 you can do @TransactionAttribute(REQUIRES_NEW) to demarcate separate transactions per request, seam POJO transaction management does not allow this

For the second q - What are the demerits of having an extended persistence context (even in temporary conversations)?
Actions
4. Re: Seam withouth EJB3 tradeoffs (discussion from Seam Framework book 2nd edition)

swd847 Mar 6, 2009 1:13 AM (in response to infinity2heaven)

@Transactional does not support REQUIRES_NEW. All it supports are REQUIRED, MANDATORY, SUPPORTS, and NEVER (see TransactionPropagationType.java).

As for the second question I use it for reporting for a large number of clients, if you load every client data into the same entity manager it will use up a lot of memory, which increases flush time significantly. Instead I run every report inside a new transaction with a transaction scoped entity manager.
Actions
5. Re: Seam withouth EJB3 tradeoffs (discussion from Seam Framework book 2nd edition)

swd847 Mar 6, 2009 1:15 AM (in response to infinity2heaven)

Additionally, you cannot use REQUIRES_NEW with a seam managed persistence context, you have to use @PersistenceContext.
Actions
6. Re: Seam withouth EJB3 tradeoffs (discussion from Seam Framework book 2nd edition)

joblini Mar 6, 2009 2:13 AM (in response to infinity2heaven)

Pojo Tradeoffs:

- No support exists for declarative method-level transactions in Pojos, Instead you can configure Seam to demarcate a database transaction from the moment the web request
is received until the response page is rendered

What does this mean? Isn't @Transactional on method level support declarative transactions on pojo? This is a strong statement and can shun away people from adopting Seam

Demarcation around the web request makes sense, and works well.

- No transaction or component level persistence context exists. All persistence contexts in Seam Pojos are extended

what does that mean wrt to Seam jpa booking example?

Sorry, don't understand the question.

- No Java Remoting (RMI) into Seam Pojo method exists

Does that mean, we can't use GWT?

RMI has nothing to do with GWT. RMI allows a Java client to call methods on an EJB.
Seam remoting (not Java remoting) is what supports GWT.
Actions

Go to original post