openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Lee (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-891) JPA2 LockTypeMode Support
Date Tue, 10 Mar 2009 16:20:50 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680522#action_12680522
] 

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 configuration values.

1) The original thought was the new pessimistic lock mode type is only related to jpa spec,
therefore it is not push down to say fetch configuration in the kernel layer, which does not
know anything about the the new lock levels, to handle the processing. I am trying to encapsulate
this in the persistence 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 touching
the JDBCConfiguration object) but still have to find a way to set the JDBCFetchConfiguration
isolation level somehow. If we can find a solution to this problem, then we can avoid the
dependency of openjpa-jdbc from openjpa-persistence.  One thought is to defer the hint/property
process further down the path and by setting the isolation property, we can de-couple the
dependency.

2) If we process the JPA behavior in the FetchConfiguration, that also means the kernel is
aware of the JPA personality's behavior. Is that what we want.

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

4) The intent of using IntValue to process the property value is to keep the 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 many valid types. 

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 either a) always do 1 push and set
the value in the fetch configuration (cleaner in code path, no if(!fsPush) conditional processing
)  or b) push only if 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
>
>


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


Mime
View raw message