Wiki Yes, I intended to put that in the wiki, but first I wanted it to be reviewed ;).
Why is Id Long? - Integer might be too small *g* - Using a hull class (Long instead of long) makes it easy to have entities without Id (necessary in transient/new or removed state), since the Id can be "null" then. You could use long (the primitive, not the hull class), but then you would need to explicitely define a "no id state" (e.g. -1 or 0) as far as I know. - It's also possible to define other "simple" classes, e.g. String as an Id. This could be useful e.g. for unique usernames. Even "complex" classes can be used via @EmbeddedId, and those complex classes need to be annotated with @Embeddable... but ...WHOW... this is going way to far for a newbie tutorial and I cannot think of many useful cases ;). Flush at method boundary Thanks for that hint. That's what I didn't know. However, sometimes it's useful to flush before, e.g. to easily recognize database constraint violations and then add a message and perform a rollback. Rollback on Exceptions - There's something I'd like to add: When saying "rollback" I usually talk about rollbacks of EJB transactions! Usually changes are made to an entity during a method invocation. If everything works fine, flush() is performed at method end. If an exception occured or setRollbackOnly() was called, then flush() will not be called. So the database remains untouched, but the entity keeps its "dirty" data for now. That's how EJB transactions work. Other case: flush() is explicitely called in the method. Then EJB starts a database transaction and sends the update/insert/delete statements to the database. If the method ends without exceptions, then the database commit will be called, otherwise the database transaction will be rollbacked. So please distinguish between EJB and database transactions ;). I hope I made clear how they work together. (All I said here is what I observed, and it seems to be sensible to me). - Well, I talked about RuntimeExceptions as you cannot compile without catching "normal" exceptions. Ok, you can add "throws Exception" to your method signature in order to see what happens if normal exceptions occur. This doesn't make sense since the page you're on will crash, but even in this case a rollback will be performed (I just tested it ;)). But all in all you're right, rollbacks happen after all types of exceptions, but usually you catch normal exceptions ;). btw: It's never a fault to add try...catch... around critical blocks in order to keep your app in a fine state. Catch exceptions, add a message to the user, and explicitely use ejbctx.setRollbackOnly() (@Resource javax.ejb.SessionContext ejbctx). Otherwise your app will crash with ugly exception stacktraces shown to the user - and though the transaction might be rollbacked automatically this just ain't beautiful ;). - I think that it's EJB3 that cares about the exception since it even cares about the transaction. But I'm not 100% sure about that. Maybe the experts can say something about that ;). Seam Managed Persistence Context I must confess that I never ran into LazyInitializationExceptions (abbr. LIE). I use an Extended Persistence Context in a Conversation scoped Stateful Session Bean. And when accessing related entities the EntityManager lazily fetches them without complaint. Don't ask me why. Maybe you can add a case where the LIE occurs. List, setParameter Jep, you're right ;). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964372#3964372 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964372 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
