If loading your configuration takes a long time, you probably haven't 
updated the DTD reference in the XML files; using the Version 2 
reference works, but the XML parser has to resolve the DTD - this 
takes some time per mapping file. (Or, if you're behind a firewall, it 
may break). NB: This means you'll have to either give up on XDoclet-
generated mapping files, or update the XDoclet template by hand to use 
the right DTDs.

If you get errors about null-arg-constructors, either make the class 
have a package-visible default constructor OR mark the class as non-
lazy loaded.

The bulk DELETE queries do not behave the way the old Session.delete
(HQL) method; keep using the classic interface for older stuff and 
migrate with care. In particular, bulk DELETE queries do not cause 
cascade-deletes.

However, make _sure_ you're using the classic interface; if you still 
use the standard interface, it will compile, but you're invoking the 
Session.delete(Object) method, and you get an error about 
java.lang.String not being a persistent class at runtime.

The relevant section of the EJB 3 Persistence spec to read for the 
bulk update/delete is Section 3.11 (at least in the 2nd public draft).

Test all queries throughly; the HQL syntax is slightly different in 
some areas, and can cause parsing problems. (Named queries help here: 
they get parsed at load time)