EJB3 Persistence
by Jonathan
In October I went to a seminar on EJB3 persistence, courtesy of the BEA UG. The speaker was Patrick Linskey, co-author of "Bitter EJB". I wrote these notes at the time but thought I'd repost them here, as we'll be talking a lot more about EJB3.
The EJB3 standard is getting closer to being finalised - they hope to have it done by March or so in order to have the TCK and everything ready for next year's Java One in May.
The EJB3 persistence spec:
Compulsory superclasses/interfaces are also out of the window (wow - you can do actual OOP with these classes!) but sadly, they are required to have an explicit identity/version field. (I suspect that JDO vendors who make EJB3 persistence modules are likely to relieve their users of this burden by continuing to offer enhancement as an option.)
There are attach/detach semantics not unlike JDO2, although detach is implicit at the end of every transaction. I suppose this goes some way to easing the fact that the sophisticated lifecycle of JDO objects, with the invaluable hollow state, has been left out. Fetch groups are also missing.
EJBQL is similar in features to JDO2, and therefore way in advance of EJB2 (quote "EJBQL 2 was half-baked; we've tried to fully bake it"). For example it has named queries. However its syntax is SQL-like, like earlier EJBQL, rather than Java-like like JDO. This is pretty reasonable given the wide understanding of SQL, even though, like in JDO there is nothing in EJB3 persistence to say you must use JDBC underneath; it can be used on top of object DBs, flat XML files or anything else (JDO is apparently used for cellphone/PDA apps). Native SQL is not supported (a Very Good Thing IMO) and neither is getting a JDBC connection from the EM.
EJB3 persistence isn't as bad as I thought it might be, but it's still a cut-down JDO, and nothing in the talk suggested why Java needs two persistence standards (Patrick didn't address the politics of it at all). But if the likes of Oracle wanted to get people building their proprietary dialect of SQL into Java code, they've clearly failed, which makes the whole thing seem a bit pointless. Nevertheless, EJB3 persistence is the standard which will have the widest industry backing (despite the lack of any good reason, so far as I can see) and so will inevitably be important in the future.
In October I went to a seminar on EJB3 persistence, courtesy of the BEA UG. The speaker was Patrick Linskey, co-author of "Bitter EJB". I wrote these notes at the time but thought I'd repost them here, as we'll be talking a lot more about EJB3.
The EJB3 standard is getting closer to being finalised - they hope to have it done by March or so in order to have the TCK and everything ready for next year's Java One in May.
The EJB3 persistence spec:
- is being developed by an expert group separate to the main EJB3 spec, and will eventually be a separate JSR
- is a pluggable, independent piece of JEE5 (Patrick agreed with me that this gradual breaking-into-pieces of JEE has interesting implications for open source, since it lowers the bar to entry for people to just make one piece)
- is a cut-down version of JDO
- is aimed at ease of use
- can be used via annotations (like everything else in JEE3) or via XML files (XML takes precedence over annotations)
Compulsory superclasses/interfaces are also out of the window (wow - you can do actual OOP with these classes!) but sadly, they are required to have an explicit identity/version field. (I suspect that JDO vendors who make EJB3 persistence modules are likely to relieve their users of this burden by continuing to offer enhancement as an option.)
There are attach/detach semantics not unlike JDO2, although detach is implicit at the end of every transaction. I suppose this goes some way to easing the fact that the sophisticated lifecycle of JDO objects, with the invaluable hollow state, has been left out. Fetch groups are also missing.
EJBQL is similar in features to JDO2, and therefore way in advance of EJB2 (quote "EJBQL 2 was half-baked; we've tried to fully bake it"). For example it has named queries. However its syntax is SQL-like, like earlier EJBQL, rather than Java-like like JDO. This is pretty reasonable given the wide understanding of SQL, even though, like in JDO there is nothing in EJB3 persistence to say you must use JDBC underneath; it can be used on top of object DBs, flat XML files or anything else (JDO is apparently used for cellphone/PDA apps). Native SQL is not supported (a Very Good Thing IMO) and neither is getting a JDBC connection from the EM.
EJB3 persistence isn't as bad as I thought it might be, but it's still a cut-down JDO, and nothing in the talk suggested why Java needs two persistence standards (Patrick didn't address the politics of it at all). But if the likes of Oracle wanted to get people building their proprietary dialect of SQL into Java code, they've clearly failed, which makes the whole thing seem a bit pointless. Nevertheless, EJB3 persistence is the standard which will have the widest industry backing (despite the lack of any good reason, so far as I can see) and so will inevitably be important in the future.