Skip to main content

PersistenceRA

11 replies [Last post]
baranowb
Offline
Joined: 2006-01-09
Points: 0

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 ?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ivelin
Offline
Joined: 2003-07-13
Points: 0

Sorry for coming late to the party. Its an important discussion. Notes below:

> Questions risen so far:
>
> * do we really need JPA - if not, what is the
> approach?

I think so. Practice dictates that there is a need for a rich and highly performant O/R mapping API.

> * should RA aim to event driven model?

not necessarily. I would suggest a sync interface staying as close to the intended use of JPA as possible. Let's have user feedback steer future direction. There are other ways for applications to decouple their persistence logic into separate asynchronous components that use a synchronous Persistence RA in turn.

...
> 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?

One suggestion for mapping JPA to JSLEE RA is as follows:

JPA EntityManagerFactory -> same name SBB interface offered by the RA

JPA EntityManagerFactory.createEntityManager() -> same for the RA, with the comment that the resulting EntityManager is the JSLEE activity that the SBB can store in a CMP filed and refer to it multiple times throughout the SBB lifespan.

This method will create an EntitiyManager instance with Container-managed Transaction-scoped Persistence Context. The resulting EntityManager will be the Persistence RA activity. For now there will be no events fired on this activity.

Since EntityManager is not thread safe, each SBB entity will have to obtain one for itself.

An SBB entity will call EntityManager.close() at the end of the SBB lifecycle or at a time when the SBB knows it will no longer need the EntityManager to allow the RA to clean up any allocated resources.

For reference to JPA see ejb-3_0-fr-spec-persistence.pdf

> * 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=887
> 5).

let's keep profiles as a separate topic for now. Based on usage patterns of the Persistence RA, we will come up with best practices for one versus the other.

> * 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.

I am sticking to my recommendation. EntityManagerFactory is intended to work with one datasource, and intuitively this extends to the RA which exposes the factory.

> * 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 ?

I don't see a need at the moment for anything that cannot be handled via Container managed transaction scoped persistence context.

Ivelin

baranowb
Offline
Joined: 2006-01-09
Points: 0

Finnaly :)

Ok to make it clear, and have well defined requierements for prototype:

- synchronous - blocking
- RAs Sbb interface exposes EntityManagerFactory method
- provided EntityManager object is stripped of TX methods - as JTA Txes are considered atomic - each event in Sbb is such operation
- each EntityManager become activity(? - did I understand it clearly)

> > * 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.
>
> I am sticking to my recommendation.
> EntityManagerFactory is intended to work with one
> datasource, and intuitively this extends to the RA
> which exposes the factory.
>

Actually what is happening is that EntitymanagerFactory creates EM instances for particular [b]persistence unit[/b] - in persistence unit we specify data source taht will be used, so we can have multiple persistence units, with one DS, (n-1) or mapping more towards 1-1 (one persistence , one DS)

> I don't see a need at the moment for anything that
> cannot be handled via Container managed transaction
> scoped persistence context.

I wasnt sure of that, I have little experience with apps in JTA using JPA (I begging to love those abreviations, sounds like "You are in the army now" - LZ,ETA,EP,ASAP...), that was my understanding, but its better to ask.

> Ivelin

ivelin
Offline
Joined: 2003-07-13
Points: 0

> - synchronous - blocking
> - RAs Sbb interface exposes EntityManagerFactory
> method

the SbbInterface can extend the EntityManagerFactory interface.
The way an EntityManagerFactory is created and made available in JNDI by the RA is up to the RA. I am suggesting for starters that we allow configuration of one persistence unit that corresponds to the one EntityManagerFactory provided by the RA. Keeps things simple. We will soon know if that proves inflexible and needs to change.

The SBB Interface needs to only implement createEntityManager(). The rest of the EntityManagerFactory methods can throw UnsupportedOperationException.

> - provided EntityManager object is stripped of TX
> methods - as JTA Txes are considered atomic - each
> event in Sbb is such operation

yes, but can you enumerate the tx methods you have in mind, to be sure we're in sync?

> - each EntityManager become activity(? - did I
> understand it clearly)

yes. Since its not thread safe, only one SBB Entity can deal with an Entity Manager at a time, which makes it a good choise for activity.

>
> Actually what is happening is that
> EntitymanagerFactory creates EM instances for
> particular [b]persistence unit[/b] - in persistence
> unit we specify data source taht will be used, so we
> can have multiple persistence units, with one DS,
> (n-1) or mapping more towards 1-1 (one persistence ,
> one DS)
>

You are correct. As said above, my preference is 1 persistence unit and 1 entity manager factory per RA entity.

baranowb
Offline
Joined: 2006-01-09
Points: 0

>
> yes, but can you enumerate the tx methods you have in
> mind, to be sure we're in sync?
[code]
/**
Returns the resource-level transaction object. The EntityTransaction instance may be used serially to begin and commit multiple transactions.
*/
EntityTransaction getTransaction()

/**
Indicate to the EntityManager that a JTA transaction is active. This method should be called on a JTA application managed EntityManager that was created outside the scope of the active transaction to associate it with the current JTA transaction.

*
void joinTransaction()

[/code]

Plus methods from EntityTransaction class.

> yes. Since its not thread safe, only one SBB Entity
> can deal with an Entity Manager at a time, which
> makes it a good choise for activity.
>
So RASbb interface would return EM instance, which become activity in RA, Sbb would have to store it in cmp since there is no way of obtaining the same instance twice (or can we add simple naming? - but this can be covered by naming acis, create aci for EM, and name)

ivelin
Offline
Joined: 2003-07-13
Points: 0

> EntityTransaction getTransaction()
> void joinTransaction()
> Plus methods from EntityTransaction class.

ok

> So RASbb interface would return EM instance, which
> become activity in RA, Sbb would have to store it in
> cmp since there is no way of obtaining the same
> instance twice

yup

> (or can we add simple naming? - but
> this can be covered by naming acis, create aci for
> EM, and name)

sorry, don't follow

baranowb
Offline
Joined: 2006-01-09
Points: 0

> > So RASbb interface would return EM instance, which
> > become activity in RA, Sbb would have to store it
> in
> > cmp since there is no way of obtaining the same
> > instance twice
>
> yup

Well than here arises simple question - what if someone does bad thing and does clean after himself and leave a lot of instantiated EM ? It can be implementation dependant, and not considered in ra type.

> > (or can we add simple naming? - but
> > this can be covered by naming acis, create aci for
> > EM, and name)
>
> sorry, don't follow

Well either sbb coudl use named acis here or ra could provide some simple name-em mapping, but that doesnt seem very good idea.

I think its enough data to contribute ra type, seems clear what we need and how.

ivelin
Offline
Joined: 2003-07-13
Points: 0

> > > So RASbb interface would return EM instance,
> which
> > > become activity in RA, Sbb would have to store
> it
> > in
> > > cmp since there is no way of obtaining the same
> > > instance twice
> >
> > yup
>
> Well than here arises simple question - what if
> someone does bad thing and does clean after himself
> and leave a lot of instantiated EM ? It can be
> implementation dependant, and not considered in ra
> type.
>

Good question. I think it goes back to the issue that Eduardo brought up in bugzilla about the SLEE asking periodically an RA whether it wants to remove activities that have not been in use for some time.

baranowb
Offline
Joined: 2006-01-09
Points: 0

Isnt there anyone who has had more experience with JPA? or has comments on what was proposed?

baranowb
Offline
Joined: 2006-01-09
Points: 0

> Questions risen so far:
>
> * do we really need JPA - if not, what is the
> approach?
Eduardo also "fears" about latency difference between ORM and plain JDBC

Possible answers:

* if we wont use some standard - just plain JDBC we would propably end up just having simple proxy - which would have need to hav econfigurable drivers etc.. Consider scenario where we would use plain JDBC - what should we implement? Why we would need RA to do that - each service/scenario will have its own needs on jdbc persistence and querries, furthermore what about events/activities/lifecycle - With JPA implementations (eg hibernate) we just expose some predefined elements(seems like well defined :))
* latency - thats why I have introduced async execution classes for operations - I wasnt sure how high latency can we expect - DB vendors/JPA impl doesnt mention about it, its against their bussines.
* latency - depends on settings - if lazy fetching is dissabled or used properly its not so big problem I think

eduardomartins
Offline
Joined: 2005-10-10
Points: 0

copy & paste

"I'm not a expert on JPA but, on first thoughts, seems far too heavy, so I
would like to know more about this issue. I would appreciate if you can say
I should not be worried :)

On the sketch ... I fear trouble on the async model, because of JPA
transactions. Imagine you have logic that depends on 2 queries, on async how
would you make the 2 SLEE transactions "feel" as just one? What would happen
when you commit one and the second fails."

baranowb
Offline
Joined: 2006-01-09
Points: 0

Im not an expert too however to my knowledge if JPA/Hibernate is urn in managed env - if JTA tx is rolled back so are underlying JPA Txs.

I think there could be a way to attach to current JTA tx - however yes thats a problem if we have two independent queries to db in two different JTA tx and we want one to to be rolled back becaose second one ( in order ) failed.

However nothign is gained when somethiing is not sacrificed. Either we end up having JPA functions blocking sbbs or we loose some conviniency in handling JPA txs.

Maybe there is a way of overcoming it, any ideas?