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