October 11, 2005

EJB3 Persistence

Went to a seminar on EJB3 persistence, courtesy of the BEA UG (not sure how I got onto their email list!). The speaker was Patrick Linskey, co-author of "Bitter EJB".

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 JEE3 (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)

Persistent objects in EJB3 are managed by an EntityManager and replace entity beans altogether. The concept of local/remote interfaces is gone; you always need a local EntityManager which is reached via a factory, just like JDO. Also like JDO, EMs can be used outside of a JEE container which is a boon for unit testing. Another similarity is that EMs can use JTA or explicitly coded transactions.

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 fields. (Patrick told me at the pub afterwards that JDO vendors who make EJB3 persistence modules are likely to relieve their users of this burden by continuing to use enhancement.)

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 isn't as good as 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) and so will inevitably be important in the future.


- 5 comments by 2 or more people Not publicly viewable

  1. :: deer in the headlights eyes ::

    11 Oct 2005, 15:45

  2. Chris May

    Some Qs:

    Presumably fetch groups (and other loading optimisations like join depths, eager/lazy associations, page sizes etc) will still be supported as vendor extensions, though? Otherwise it's worse than useless.

    I presume (since it was Patrick presenting) that SolarMetric now have an EJB3 implementation – good if so, since the Hibernate one could do with some competition. Have any of the other JDO vendors managed to come up with one yet?

    Early on, there was some talk of JSR220 being targetted specifically at ORM, rather than persistence generally. Has that now been dropped in favour of a more generic API? I can see pros and cons for both; architecturally it's nice not to have to worry at all about your persistence, but from an implementation POV it can be a considerable simplification to be able to say ' we will always map to an RDBMS' (and 99.9%* of J2EE projects do)

    On the subject of hiding the underlying connection details, and disallowing SQL, I think this is a double-edged sword, and may be a significant disadvantage in some situations. Two example scenarios:

    1) You want to do hierarchical queries against a 10-million-row oracle database – using oracle's CONNECT BY syntax you'll get the data back in milliseconds; if you have to walk an entire object graph it will take who knows how long.

    2) You're interfacing with a 10 year old life-assurance backend written in PL-SQL. All DB access happens through stored procedures that return table-type structures – so you must call a stored procedure, not a piece of SQL, to update the DB or run a query.

    These aren't terribly unusual use cases – though I suspect that what will probably happen is that vendors will provide extension points outside the spec. to handle them – at least, that's what Hibernate does.

    * I made that figure up. But I bet it's not far off.

    11 Oct 2005, 16:37

  3. There will be tons and tons of vendor extensions. Which makes a bit of a mockery of having a new standard.

    Patrick was presenting in his capacity as a member of the expert group (he actually didn't mention JDO once – all the comparisons with JDO are mine). But yes, kodo can do all this stuff – the proposals are still changing from week to week so there isn't really an EJB3 to have an implementation of – Hibernate is full of hype. Since EJB3 is just a lowest-common-denominator between Hibernate and JDO, I'd be amazed if any JDO vendor didn't have an EJB3 solution.

    My impression (from Java One as well as this) is that JSR220 is all about getting something easy to use to replace entity beans; there's no emphasis on ORM although some aspects of it obviously address ORM directly, for example you have separate persistence and ORM metadata XML files, exactly like JDO. Sun are driving JEE3 generally in the direction of ease of use and using annotations everywhere. I don't think annotations fit very well with ORM - I don't want to have to recompile Java classes when the RDBMS structure changes – but there it is.

    11 Oct 2005, 17:48

  4. Chris May

    I'd be amazed if any JDO vendor didn't have an EJB3 solution.

    I'm sure they'll all have one eventually, I was interested more to see if anyone's keeping up with the spec so far. Quite a few of the JDO vendors don't have an EJB3 implementation yet as far as I can see, which would suggest that either they're keeping it very quiet, or they're prepared for a fair delay between the spec being finalised and their implementation being available.

    Although it is still changing, the spec is not (AFAICS) changing that fast any more. The hibernate implementation does carry a fair bit of hype ( it comes from Jboss, after all :-) ) but it is at least a reasonably-working implementation. Hopefully having Kodo competing will encourage them to smooth off some of the rougher corners.

    One more question: Did Patrick cover the issue of who EJB220 is now being targetted at? It seems to me that there are basically two groups of J2EE developers:

    • EJB 1 / 2 users – aren't going to migrate existing apps, because it's just too different
    • Other ORM (JDO / Hibernate / Toplink) users – aren't going to migrate because at best it's extra effort for no return, and at worst they lose features.

    So I wonder if there might be quite a slow uptake. Really the only motivations would be (a) You care a lot about being compliant with the latest-and-greatest standard*, or (b) You're starting a project from scratch and have no investment in technology that you don't want to keep (though this might well be true for a brand-new development from a team that's done EJB2). Someone needs to come up with a 'killer feature' of EJB3 persistence that none of the competition has.

    * "If I only wanted one standard, I'd have used .NET " :-)

    11 Oct 2005, 23:35

  5. What happened with JDO2 was that all the main vendors tracked the evolving standard in their implementations, but didn't announce compliance until the TCK proved it (there were JDO2 features in Lido a year or more before the standard finally passed). I imagine it's the same with EJB3. I haven't really looked into it.

    I think the proposition with JEE3 including EJB3 is that it's supposed to be so vastly easier to work with, that anyone would naturally consider it for new projects. Given an existing skills base though, I agree that it might well have a pretty slow takeup. Patrick didn't address this but he did get a show of hands what JDK versions everyone was using – as many people were using 1.3 as 1.5, and one guy was still writing to 1.2. Despite being out for a year (1.5 years, effectively) JDK1.5 still seems to be regarded with suspicion in some quarters. It's occurred to me that by making JEE3 so heavily dependent on 1.5 language features (especially annotations and generics), Sun may be trying to drive the development world forwards a bit faster.

    12 Oct 2005, 09:59


Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

Trackbacks

October 2005

Mo Tu We Th Fr Sa Su
Sep |  Today  | Nov
               1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31                  

Search this blog

Tags

Galleries

Most recent comments

  • Good luck, Jon. Thanks for your helps in the past 3 years. by Hongfeng Sun on this entry
  • Good luck in the future by Mathew Mannion on this entry
  • It is indeed. And when I look out of the nearest window at work, I see Charter Avenue, where parking… by on this entry
  • There's very little free parking on the rest of campus, so why should westwood be treated favourably… by on this entry
  • I live in Earlsdon. I can drive, but haven't since I came to University here in 1990 (I never left –… by on this entry

Blog archive

Loading…
Not signed in
Sign in

Powered by BlogBuilder
© MMXIV