Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <1650370505.1236702050804.JavaMail.jira@brutus>
Date: Tue, 10 Mar 2009 09:20:50 -0700 (PDT)
From: "Albert Lee (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Commented: (OPENJPA-891) JPA2 LockTypeMode Support
In-Reply-To: <762876655.1233678239877.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/OPENJPA-891?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D126=
80522#action_12680522 ]=20

Albert Lee commented on OPENJPA-891:
------------------------------------

Pinaki,

Thanks for your time reviewing the code and your architectural insight into=
 the code base.

There are 2 functions in the implementation:
- setting the correct (jpa2) lock level in the fetch configuration so that =
the datastore can issue the correct SQL
- process the related input properties and set up the appropriate fetch con=
figuration values.

1) The original thought was the new pessimistic lock mode type is only rela=
ted to jpa spec, therefore it is not push down to say fetch configuration i=
n the kernel layer, which does not know anything about the the new lock lev=
els, to handle the processing. I am trying to encapsulate this in the persi=
stence layer. The attribute to implement and differentiate PESSIMISTIC_READ=
/WRITE is based on the isolation level being set in the fetch configuration=
, hence the code is getting the dictionary to see if it is supported by the=
 db and then set the isolation in the JDBCFetchConfiguration. Both objects =
are in the jdbc-jdbc layer.  We can skip the db checking (and avoid touchin=
g the JDBCConfiguration object) but still have to find a way to set the JDB=
CFetchConfiguration isolation level somehow. If we can find a solution to t=
his problem, then we can avoid the dependency of openjpa-jdbc from openjpa-=
persistence.  One thought is to defer the hint/property process further dow=
n the path and by setting the isolation property, we can de-couple the depe=
ndency.

2) If we process the JPA behavior in the FetchConfiguration, that also mean=
s the kernel is aware of the JPA personality's behavior. Is that what we wa=
nt.

3) Point taken. I will move the (expensive) getPropertyKeys() call out of t=
he loop and request it once.

4) The intent of using IntValue to process the property value is to keep th=
e exact same behavior as if it is being process by the configuration plugin=
 framework. Since the property map takes Object as value, so it can take ma=
ny valid types.=20

5) The current implementation will only do at most 1 push and 0 if no fetch=
 configuration is changed. That is the fcPushed is for.  I was debating eit=
her a) always do 1 push and set the value in the fetch configuration (clean=
er in code path, no if(!fsPush) conditional processing )  or b) push only i=
f needed (current implementation.)

Comments/suggestions are welcome.
Albert Lee.

> JPA2 LockTypeMode Support
> -------------------------
>
>                 Key: OPENJPA-891
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-891
>             Project: OpenJPA
>          Issue Type: Sub-task
>          Components: jpa
>    Affects Versions: 2.0.0
>            Reporter: Albert Lee
>            Assignee: Albert Lee
>             Fix For: 2.0.0
>
>


--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.