Well, after looking at the TopLink code for about 30 minutes and thinking... Damm, I can understand this, this is nice code! Set a few break points and started tracing the descriptor load... Nothing obvious there so I recreate the problem and started tracing a call to Toplink from my application's persistence service. Ta Da...
session = (Session)SessionManager.getManager().getSessions().values().toArray()[0];
I can remember writing this (condensed) code 6 months ago and thinking it wasn't safe but the relationship between the Persistence Unit Name and TopLink session never even occurred to me, not to mention I've seen this used in non-JPA persistence services for a few years. If it's good enough for everyone else, it must be good enough for me (it must have been a late night since this is not my usual attitude towards coding). This time around as soon as I saw the getSessions().values().toArray()[0] I knew what was going on. A simple change to get the session by name and all was good with the world.
All this because the em.getDelegate() returns null if you are not running in a transaction so there is no way to use TopLink Expressions in read-only DAO's without getting the server session from the SessionManager. Why can't it just work one way!
Oh well, at least I found my problem and there's a trace out there for anyone else tripping over this.
Sean
[Message sent by forum member 'redmondcs' (redmondcs)]
http://forums.java.net/jive/thread.jspa?messageID=286614