Hey guys, there has been disscusion on persistence in SLEE, and idea was to create RA for this. Process has been started recently, here is base which will hopefuly be match that lits disscusion: http://groups.google.com/group/mobicents-public/web/persistence-ra-design
This is initial idea, so please be gentle.
Idea is to aim at async execution of some parts of JPA API - possibly those which introduce biggest latency.
Questions risen so far:
* do we really need JPA - if not, what is the approach?
* should RA aim to event driven model? - SLEE engine shouldnt be burdened with high latency operations - like db access etc - I cant find word about in specs but Query operations do block - so its seems resonable asumption that it does all the magic
connected to db -> pojo swap. In other words sbbs shoudl invoke some method that will schedule execution of querries/other EM operations or should those operations be invoked directly on Query/EM objects - causing sbb to be blocked until result arrives?
* in related thread there was a lot of information about Profiles - does this fall in our current needs for persistence RA ? If so , what is expected correlation between persistence and profiles( http://forums.java.net/jive/thread.jspa?messageID=88745).
* if RA should aim for event driven model - what about activities? - JPA doesnt give anything like SIP tx or anything else - my first thought was to use single null activity ( or activity per event type - see diagram) which would be alive / or kept alive as long as PersistenceContext is open - EntityManager is not closed. Looks like this approach would solve problems with having too many activities, or keeping track of live and dead activities.
* what with multiple persistence units - Ivelin suggested that it would be better to have 1-1 relation between RA-DB. However it seems quite easy to have one RA with multiple persistence units defined (with different data sources as well, or even shared DS), however sbb developers will have to keep track of what they are doing.
* PersistenceRAEntityManager doesnt expose TX related methods - as I assumed that it will run in JTA env, however are there any counter arguments? Can there be any need for more fine grined operations withing JTA tx ?