You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Pinaki Poddar (JIRA)" <ji...@apache.org> on 2007/02/15 20:27:05 UTC
[jira] Created: (OPENJPA-151) Added field in enhanced vesrion of a
class is not serialized. Hence the change in detached+serialized instances
is not registered under certain conditions.
Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: OPENJPA-151
URL: https://issues.apache.org/jira/browse/OPENJPA-151
Project: OpenJPA
Issue Type: Improvement
Components: kernel
Reporter: Pinaki Poddar
Assigned To: Pinaki Poddar
Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
1. class A has one-to-one relation to class B
2. an instance a of A is related to b1 of B. b2 is another instance of B.
3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
4. in the remote process a* is associated with b2*
5. a* is merged to the original process.
The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of
a class is not serialized. Hence the change in detached+serialized
instances is not registered under certain conditions.
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475099 ]
Pinaki Poddar commented on OPENJPA-151:
---------------------------------------
> Why will this require re-enhancement?
======================================================
Previous enhancement:
private static final void pcSetdepartment(Employee employee, Department department1) {
if(employee.pcFlags == 0) {
employee.department = department1;
return;
}
if(employee.pcStateManager == null) {
employee.department = department1;
return;
} else {
employee.pcStateManager.settingObjectField(employee, pcInheritedFieldCount + 0, employee.department, department1, 0);
return;
}
}
================================================
Enhanced version once pcFlags is removed:
private static final void pcSetdepartment(Employee employee, Department department1) {
if(employee.pcStateManager == null) {
employee.department = department1;
return;
} else {
employee.pcStateManager.settingObjectField(employee, pcInheritedFieldCount + 0, employee.department, department1, 0);
return;
}
}
==================================================
If the previous enhanced version is used, the behaviour of serialized domain class will remain unchanged even with new OpenJPA runtime (i.e. PC/SM interfaces without calling back on pcReplaceFlags()).
But all this optimization to short-circuit StateManager mediation is only happening with JDO facade that too when the accessed field in not in default fetch group.
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-151) Added field in enhanced vesrion of a
class is not serialized. Hence the change in detached+serialized instances
is not registered under certain conditions.
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pinaki Poddar updated OPENJPA-151:
----------------------------------
Attachment: PCEnhancer.AddVersion.Diff.txt
Added a public int getEnhancementContractVersion() to all enhanced classes.
Please review these baby steps into bytecode manipulation.
The diff also contains removal of pcFlags related changes.
It does not include the change in PersistenceCapable interface.
1. Should the method be static?
2. The ENHANCER_VERSION is public static final in PCEnhncer. So the user can:
PersistenceCapable pc = ...
if (pc.getEnhancementContractVersion() < PCEnhancer.ENHANCER_VERSION)
// warn or throw exception
3. What is a good central location to add the above check?
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt, PCEnhancer.AddVersion.Diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of
a class is not serialized. Hence the change in detached+serialized
instances is not registered under certain conditions.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475087 ]
Patrick Linskey commented on OPENJPA-151:
-----------------------------------------
> Please note that if this proposal is accepted by the community, it will require reenhancement
> of existing domain classes. The change will impact the internal StateManager and
> PersistenceCapable API (essentally removal of certain methods than any other behavioural
> change).
Why will this require re-enhancement? The previously-enhanced classes will just have some extra methods that are no longer part of the interface.
Classes enhanced with the new version will not work with older OpenJPA versions, though.
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of
a class is not serialized. Hence the change in detached+serialized
instances is not registered under certain conditions.
Posted by "Abe White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475093 ]
Abe White commented on OPENJPA-151:
-----------------------------------
> Why will this require re-enhancement?
We'll no longer be setting pcFlags values -- the callbacks won't even exist to do so. Instances of classes that aren't re-enhanced will therefore never get their pcFlags set to LOAD_REQUIRED as needed to ensure their StateManagers are able to intercept all field access.
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-151) Added field in enhanced vesrion of a
class is not serialized. Hence the change in detached+serialized instances
is not registered under certain conditions.
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pinaki Poddar updated OPENJPA-151:
----------------------------------
Attachment: diff.txt
Prposed changes to remove pcFlags from enhanced classes
i. remove pcFlags related interface method from PersistenceCapable and StateManager
ii. remove pcFlags related code generation from PCEnhancer
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of
a class is not serialized. Hence the change in detached+serialized
instances is not registered under certain conditions.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475181 ]
Patrick Linskey commented on OPENJPA-151:
-----------------------------------------
> 1. Should the method be static?
No; it should be part of the interface.
The code looks good to me. Please make sure to run it through the Kodo test suites before committing, though -- sadly, we don't have as much enhancement coverage in the OpenJPA test suites as we should.
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt, PCEnhancer.AddVersion.Diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of
a class is not serialized. Hence the change in detached+serialized
instances is not registered under certain conditions.
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475144 ]
Pinaki Poddar commented on OPENJPA-151:
---------------------------------------
One way is to add some extra checks on isPersistenceCapable() for the deprecated pcFlags() method and warn if the enhanced version is "old". Or is that too arbitrary?
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of
a class is not serialized. Hence the change in detached+serialized
instances is not registered under certain conditions.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475100 ]
Patrick Linskey commented on OPENJPA-151:
-----------------------------------------
Maybe we should do something explicit to make sure that classes enhanced with the old enhancer can't load anymore. It sounds like currently, classes will just silently start to behave differently.
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of
a class is not serialized. Hence the change in detached+serialized
instances is not registered under certain conditions.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475155 ]
Patrick Linskey commented on OPENJPA-151:
-----------------------------------------
Another would be to add a new getEnhancementContractVersion() method to the PersistenceCapable interface. This would cause immediate breakage of the old classes, since they don't have that method, and allow us to detect other subtle behavior changes in the future by checking that the version is compatible.
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-151) Added field in enhanced vesrion of a
class is not serialized. Hence the change in detached+serialized instances
is not registered under certain conditions.
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pinaki Poddar resolved OPENJPA-151.
-----------------------------------
Resolution: Fixed
Fixed with SVN revision 511998: http://svn.apache.org/viewvc?view=rev&rev=511998
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt, PCEnhancer.AddVersion.Diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of
a class is not serialized. Hence the change in detached+serialized
instances is not registered under certain conditions.
Posted by "Abe White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475097 ]
Abe White commented on OPENJPA-151:
-----------------------------------
+1 on the patch from me. Fixes a problem and gets rid of unneeded code baggage at the same time. The re-enhancement isn't much of an issue to me -- we've required re-enhancement for various upgrades in the past and it's never been an issue with users, surprisingly enough.
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-151) Added field in enhanced vesrion of
a class is not serialized. Hence the change in detached+serialized
instances is not registered under certain conditions.
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475190 ]
Craig Russell commented on OPENJPA-151:
---------------------------------------
I'd avoid the method name getEnhancementContractVersion because this might be used by the class developer. I'd suggest PRE+GetEnhancementContractVersion instead to avoid name conflicts.
> Added field in enhanced vesrion of a class is not serialized. Hence the change in detached+serialized instances is not registered under certain conditions.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-151
> URL: https://issues.apache.org/jira/browse/OPENJPA-151
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
> Attachments: diff.txt, PCEnhancer.AddVersion.Diff.txt
>
>
> Enhancement adds a transient byte member field pcFlags to the class. This field is originally used to optimize field access/mutation i.e. to short-circuit mediation via StateManager under certain conditions (e.g. when the field is part of the default fetch group). The field is transient, perhaps, to maintain serialization compatibility. However, later changes such as DetachedStateManager and improved attach strategies have made the usage of these flag redundant.
> This issue is a proposal to remove this field from the enhanced classes. The proposed change is initiated by the following observation:
> 1. class A has one-to-one relation to class B
> 2. an instance a of A is related to b1 of B. b2 is another instance of B.
> 3. a, b1, b2 are detached, serialized, transported over the wire, desrialized in a remote process as a*, b1* and b2*.
> 4. in the remote process a* is associated with b2*
> 5. a* is merged to the original process.
> The change is not persisted when OpenJPA kernel is used with a JDO facade. It works with JPA facade.
> The initial analysis shows that the reason can be attributed to pcFlags and the optimization in enhanced classes based on to its value. Because pcFlags is not
> serialized, in a* instance pcFlags has a value of 0. Hence, the mutation of a*'s relation to b2* from b1* is not mediated via the StateManager (yes, the detached version was carrying its own StateManager). While merging the instance a* back, it was adjudged clean while actually it was dirty. In JPA facade, the enhancement process did not add the extra optimization for setter and so the cloned owner instance was righly marked dirty.
> Please note that if this proposal is accepted by the community, it will require reenhancement of existing domain classes. The change will impact the internal StateManager and PersistenceCapable API (essentally removal of certain methods than any other behavioural change).
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.