Hi Michael,
You are right, it's a type of EJB. Your question is all about
plumbing, and what I like about EJB 3 is that it does the plumbing
for you, so only have to think about pages, business services, and
entities. In other words, I suspect you'll find it easier than where
you're currently heading.
When you invoke a session bean it starts a transaction for you in its
own thread. If you have multiple simultaneous invocations of session
beans it's no problem - each one acts independently in its own
thread. If you concurrent requests to save your detached object,
they will operate in two separate transactions, and one of them will
succeed and the other will be rejected with an
OptimisticLockException (that's just Hibernate, or in fact the Java
Persistence Architecture spec, at work). That's correct behaviour.
Here's an example of some things you might like a session bean to do:
public interface IOrderServiceLocal {
Order findOrder(Order order);
void changeOrder(Order order);
List<Order> findOrders();
}
And here's an example of the bean itself - you can see it's very simple:
@Stateless
@Local(IOrderServiceLocal.class)
public class OrderService extends BaseService implements
IOrderServiceLocal {
@PersistenceContext
protected EntityManager _em;
public Order findOrder(Long id) {
Order obj = (Order) _em.find(Order.class, id);
return obj;
}
public void changeOrder(Order order) {
order = _em.merge(order);
}
public List<Order> findOrders() {
Query q = _em.createQuery("select o from Order o order by
o.customerName");
List l = q.getResultList();
return l;
}
}
As for the Order entity bean, it will be exactly the same as the
Hibernate entity you were going to code up anyway, because Hibernate
follows the Java Persistence Architecture spec which EJB 3 also follows.
As you can tell, I am almost as enthusiastic about EJB 3 as I am
about Tapestry, and for very similar reasons. If you'd like to see
them together in action, you can be up and running in about 20
minutes with Tapestry JumpStart: http://files.doublenegative.com.au/
jumpstart/
I hope this helps,
Geoff
On 19/06/2007, at 1:48 AM, Michael Sims wrote:
Hi Geoff, thanks for the response,
Geoff Callender wrote:
Do any of these problems exist if you get a session bean to do the
work for you?
For example, a page to edit the user, using a session bean called
OrderService and an entity bean (using Hibernate if you like, as I
do) called Order.
[...]
No threading issues to worry about. Isn't this simpler than roll-
your-own?
You'll have to forgive my ignorance, I'm still rather a newbie when
it comes
to Java web apps. I'm afraid I'm not familiar with what a Session
Bean is
as a proper term (if that is the way you are using it). Some
Googling shows
me that it appears to be an EJB concept. This is my first real Java
application, and I'm trying to keep it as simple as possible, so I
haven't
yet gotten into JEE, EJB, etc. I'm just doing a plain servlet on
Tomcat.
Can you tell me what is is about session beans that avoids my
problem, or
give me some pointers to documentation? If I place a detached
object in the
session bean, how is this any different from placing it in the
HttpSession?
Isn't it still possible that two concurrent threads will be given
that same
detached object? What am I missing? Thanks. ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
