ejb-3.1

When I have an @Asynchronous method in an EJB, and I don't specify the @TransactionAttribute , then how exactly does the container handle the transaction boundaries? Obviously, it can't use the calling thread's transaction, so what does it do? Same question, but regarding methods that are triggered by the TimerService. EDIT: I think I phrased that poorly. I already know that the default mode is 'REQUIRED'. So it should be safe to assume that those methods will always be called within a transaction. But my question is, what does that transaction's life-cycle look like? Does the container create

Been trying to learn what EJB beans are, what does it mean their instances are managed in a pool, blah blah. Really can't get a good grip of them. Can you explain me what they really are (practically for a Java Programmer)? What do they do? Which are their purposes? Why really use them? (Why not just stick to POJO ?) Perhaps an example application? Please refer only to updated information, that is EJB 3.1 . Dated information about EJB can be misleading. For EJB learning beginners please note: EJB are based on distributed objects , this refer to software pieces running on multiple machines

I think, I misunderstood rules of packaging ejb beans in war package. Goal: I want to use ejb beans in war package. Scenario: I have some bean in my war: @Stateless public class RegistrationServiceBean { @PersistenceContext(unitName = "Utopia") EntityManager em; public RegistrationServiceBean() {} @Schedule(hour = "*", minute = "*", second = "*/15") public void baseRegistration() { System.out.println("call from ejb!!"); } public void saveTempPartner(OasysPartnerTempEntity part) { em.persist(part); em.flush(); } } It successfully deploying to glassfish server (ogs 3.0.1) : [#|2010-07-02T16:53

So I'm running a Java EAR application on a Glassfish 3.1. I created a stateless session bean with a single annotated timer function in my EJB Module. I don't have the exact code but it looks something like this: @Stateless public class SessionTimerBean { public SessionTimerBean(){ System.out.println("Constructor Called"); } @Schedule(second="*/10", minute="*", hour="*") public void scheduleTimer(final Timer t) { System.out.println("Timer Called"); } } When I launch Glassfish the debug info seems to indicate that it recognizes the EJB timer annotations and the constructor method for the bean

I have a CDI Managed Bean (a bean annotated with @Named that is used on JSF) that has a Stateful Session Bean injected. This session bean is like a service, it has the entity manager (annotated with @PersistenceContext(type= PersistenceContextType.EXTENDED)) and expose come methods to manipulate some entities. Those entities are on the managed bean, who is ConversationScoped. Then, the JSF calls a method of the managed bean and the managed bean calls some method of the "service" (the stateful session bean). I don't know if this is the best design, but it was working well. But there's an Entity

I am preparing for the EJB certification and I am going thro the EJB 3.1 book (O'Reilly) One of the chapters discusses about JNDI, ENC and the EJB connections Can some of you give me a real life scenario of these so that I can get a better understandin Arjan Tijms JNDI in this scenario is used as a central location through which 'names' (a kind of URL) are routed to an EJB bean. Think of it how a Servlet is mapped to a URL. If EJB beans are local to an application (e.g. they reside within the web module or within the EJB module of the same EAR), then you don't necessarily need to come into

This is a follow up question to EJB3.1 Timer cancel issue I used Spring's @Scheduled earlier in my projects. Is EJB3.1 @Schedule similar to that? How does EJB3.1 @Schedule fare in Clustered environment? In a Clustered environment where there are multiple JVMs, how can we make sure only one Scheduler/Timer is run at a time? For example I want inventory level from database emailed to a customer for every hour and I don't want duplicated emails being sent out. I know work around like setting a database flag to avoid further duplication. But, I'm not seeing this as a proper solution. Any ideas on