[jira] Commented: (OPENJPA-245) Attach NEW and auto-increment identity
[
https://issues.apache.org/jira/browse/OPENJPA-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500235
]
Pinaki Poddar commented on OPENJPA-245:
---
An entity instance x which has been created by new() operator and carrying a
existing id (say idx) set by the user application is treated as detached by
merge() when the entity class is annotated with @DetachState(enabled=false).
Then merge() updates the existing database record with current state of x. If
it is not annotated with @DetachState(enabled=false), the instance x is trated
as a new instance, and if the entity is using auto-generated identity, a new
database record is created, ignoring the id set by the application. However, if
the entitymanager doing the merge() is already managing an instance with the
same identity idx then an EntityExists exception is raised.
The generated enhanced code differs based on @DetachedState setting.
So if the application has changed this setting, the entity must be enhanced
again.
Attach NEW and auto-increment identity
--
Key: OPENJPA-245
URL: https://issues.apache.org/jira/browse/OPENJPA-245
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 0.9.6, 0.9.7
Environment: jdk1.5.0_11, Win XP, Fedora Core 6, Postgres 8.1 (on
Fedora)
Reporter: Aleksandar Likic
Attachments: TestMerge.zip
According to documentation (1.2 Attach Behavior), when an entity instance is
NEW (never detached):
* If neither of the above cases apply, OpenJPA will check to see if an
instance with the same primary key values exists in the database. If so, the
object is considered detached. Otherwise, it is considered new.
This doesn't work for me - a new record in database is created on commit
instead of updating the existing one. The regular case -
detach/modify/attach works fine - the existing record is updated.
It is very easy to reproduce - just create a new instance of an entity,
assign an already existing primary key, call em.merge() and commit. A new
record will be created in database, with new, auto-generated primary key.
I stumbled on this trying to implement a web service that uses OpenJPA-based
backend. When servicing an update request, the web service instantiates a
NEW object (by performing XML de-serialization) and calls em.merge to update
the entity. A new record gets created instead of updating an existing one.
Entity class (START) --
package exaple;
public class Consumer implements java.io.Serializable {
private long id;
public long getId() {
return this.id;
}
public void setId(long id) {
this.id = id;
}
private java.lang.String firstName;
public java.lang.String getFirstName() {
return this.firstName;
}
public void setFirstName(java.lang.String firstName) {
this.firstName = firstName;
}
private java.lang.String lastName;
public java.lang.String getLastName() {
return this.lastName;
}
public void setLastName(java.lang.String lastName) {
this.lastName = lastName;
}
Entity class (END) --
persistence.xml (START) --
?xml version=1.0 encoding=UTF-8?
persistence xmlns=http://java.sun.com/xml/ns/persistence;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.0
persistence-unit name=example transaction-type=RESOURCE_LOCAL
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
!-- We must enumerate each entity in the persistence unit --
classexample.Consumer/class
properties
property name=openjpa.jdbc.DBDictionary value=postgres/
property name=openjpa.ConnectionDriverName
value=org.postgresql.Driver/
property name=openjpa.ConnectionUserName value=app_user/
property name=openjpa.ConnectionPassword value=app_user/
property name=openjpa.ConnectionURL
value=jdbc:postgresql://localhost/alikic/
property name=openjpa.Log value=DefaultLevel=WARN,SQL=TRACE/
/properties
/persistence-unit
/persistence
persistence.xml (END) --
orm.xml (START) --
entity-mappings xmlns=http://java.sun.com/xml/ns/persistence/orm;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/persistence/orm
orm_1_0.xsd
version=1.0
entity class=example.Consumer
attributes
id name=id
generated-value strategy=IDENTITY/
/id
basic name=firstName
column name=first_name/
[jira] Created: (OPENJPA-246) Interdependency of Enhancement, Detachment and Merge on detachment settings should be coherently captured
Interdependency of Enhancement, Detachment and Merge on detachment settings should be coherently captured - Key: OPENJPA-246 URL: https://issues.apache.org/jira/browse/OPENJPA-246 Project: OpenJPA Issue Type: Improvement Components: docs Reporter: Pinaki Poddar In OpenJPA, there is significant interplay between enhancement, detachment and merge operations to support a wide variety of use cases. Given that detach-modify-merge is a significant use case for multi-tier web applications built on OpenJPA, a comprehensive section that brings together how OpenJPA supports these wide variety of use cases with different detachment settings can be useful addition to the documentation. As JPA specification does not yet explicitly (i.e. via API) support detachment, these features are often OpenJPA extensions and hence such elaboration gains more usefulness. The current documentation does describe the configuration and semantics in sufficient details but such descriptions are distributed across different sections. The users often have to connect the dots for their specific use cases. The section should bring together following aspects : a) when entities are detached and how it is controlled (e.g. AutoDetach) b) what fields are detached (e.g. DetachState loaded/fetchgroups/all) c) what extra fields are added by the enhancer and how enhanced code differs based on configuration/annotation (e.g. @DetachState(enabled=true/false) d) how serialization compatibility is influenced by enhancement (e.g. whether client having access to openjpa librariers can determine whether a DetachStateManager can be associated with a detached instance) e) how the detached entity behaves (DetachStateManager) when detached (e.g. AccessUnloaded) f) how merge() determines whether an instance is detached or brand new (e.g. treatement of version field or a new instance with preassigned identity) g) performance impact on merge operation of differnt configuration choices -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-245) Attach NEW and auto-increment identity
[
https://issues.apache.org/jira/browse/OPENJPA-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pinaki Poddar updated OPENJPA-245:
--
Attachment: TestMerge.zip
Attached a test case that demonstates merge() behaviour of entities with or
without a version field and when the merged instance is a clone or a copy. A
clone is created by serialization+deserialization of the original persistent
instance. A copy is created by Java new() operator and then fields values are
set equal to the original persistent instance (including the primary key
field).
Thus we have four scenarios:
1. Unversioned + Copy
2. Unversioned + Clone
3. Versioned + Copy
4. Versioned + Clone
The first case originated this issue (at least that's what I gathered from the
description). The first case behaves 'rationally but non-intutively'. It
creates a new database record rather than updating the existing one. The
merge() operation does not see a versioned field, treats the argument instance
as a new instance, assigns a new identity (ignoring what the application has
set).
If the entity were using application identity, one would have encountered a
DuplicateKeyException of some sort, I presume but not tested here.
The rest three cases update the existing record. In the third case, the user
application has to copy the version field for merge() to treat the merged
instance 'correctly' i.e. as a update rather than an insert of a new record.
This seems to be the solution to the original use cse -- add a version field
and copy the version field to the merged instance.
Attach NEW and auto-increment identity
--
Key: OPENJPA-245
URL: https://issues.apache.org/jira/browse/OPENJPA-245
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 0.9.6, 0.9.7
Environment: jdk1.5.0_11, Win XP, Fedora Core 6, Postgres 8.1 (on
Fedora)
Reporter: Aleksandar Likic
Attachments: TestMerge.zip
According to documentation (1.2 Attach Behavior), when an entity instance is
NEW (never detached):
* If neither of the above cases apply, OpenJPA will check to see if an
instance with the same primary key values exists in the database. If so, the
object is considered detached. Otherwise, it is considered new.
This doesn't work for me - a new record in database is created on commit
instead of updating the existing one. The regular case -
detach/modify/attach works fine - the existing record is updated.
It is very easy to reproduce - just create a new instance of an entity,
assign an already existing primary key, call em.merge() and commit. A new
record will be created in database, with new, auto-generated primary key.
I stumbled on this trying to implement a web service that uses OpenJPA-based
backend. When servicing an update request, the web service instantiates a
NEW object (by performing XML de-serialization) and calls em.merge to update
the entity. A new record gets created instead of updating an existing one.
Entity class (START) --
package exaple;
public class Consumer implements java.io.Serializable {
private long id;
public long getId() {
return this.id;
}
public void setId(long id) {
this.id = id;
}
private java.lang.String firstName;
public java.lang.String getFirstName() {
return this.firstName;
}
public void setFirstName(java.lang.String firstName) {
this.firstName = firstName;
}
private java.lang.String lastName;
public java.lang.String getLastName() {
return this.lastName;
}
public void setLastName(java.lang.String lastName) {
this.lastName = lastName;
}
Entity class (END) --
persistence.xml (START) --
?xml version=1.0 encoding=UTF-8?
persistence xmlns=http://java.sun.com/xml/ns/persistence;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=1.0
persistence-unit name=example transaction-type=RESOURCE_LOCAL
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
!-- We must enumerate each entity in the persistence unit --
classexample.Consumer/class
properties
property name=openjpa.jdbc.DBDictionary value=postgres/
property name=openjpa.ConnectionDriverName
value=org.postgresql.Driver/
property name=openjpa.ConnectionUserName value=app_user/
property name=openjpa.ConnectionPassword value=app_user/
property name=openjpa.ConnectionURL
value=jdbc:postgresql://localhost/alikic/
property name=openjpa.Log value=DefaultLevel=WARN,SQL=TRACE/
/properties
/persistence-unit
/persistence
[jira] Updated: (OPENJPA-35) In-memory Delete operation fails with active DataCache
[ https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-35: - Attachment: openjpa-35.trace.txt Added a trace output of the test case that is failing. shows that the deleted instance (PObject-4501) is in L2 Cache. Please note the instance was locked and modified *after* delete by query (as we still has its reference). Does that give the cache a chance to heal? Please note that PObject-4501 has a DetachedStateManager when we lock/modify it after delete. In-memory Delete operation fails with active DataCache -- Key: OPENJPA-35 URL: https://issues.apache.org/jira/browse/OPENJPA-35 Project: OpenJPA Issue Type: Bug Components: datacache, query Environment: Only happens when DataCache is active property name=openjpa.DataCache value=true/ property name=openjpa.RemoteCommitProvider value=sjvm/ Reporter: Pinaki Poddar Priority: Critical Attachments: openjpa-35.test.zip, openjpa-35.trace.txt Delete through query such as Query query = em.createQuery(DELETE FROM Node n); query.executeUpdate(); fails with following exception (only when DataCache is active) Exception in thread main 4|false|0.0.0 org.apache.openjpa.persistence.ArgumentException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1029) at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeDelete(ExpressionStoreQuery.java:665) at org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeDelete(QueryCacheStoreQuery.java:348) at org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1012) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:768) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:831) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:827) at org.apache.openjpa.kernel.DelegatingQuery.deleteAll(DelegatingQuery.java:544) at org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:299) at control.Test.clear(Test.java:87) at control.Test.run(Test.java:37) at control.Test.main(Test.java:178) Caused by: java.lang.ClassCastException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:651) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:949) at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1018) ... 11 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache
[ https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476790 ] Pinaki Poddar commented on OPENJPA-35: -- Right -- a newly looked up copy (the copy comes out of L2 cache and not from the database where it really do not exist anymore) -- is essentially not usable i.e. any commit set containing that object fails. The L2 cache heals as soon as the commit fails. So let me summarize a) delete via query leaves a copy in the L2 cache b) the cached copy can be located via em.find() c) however, any modify operation on this ghost copy will fail d) this failure will signal to clear the copy from the L2 cache. Do you think, it is worth mentioning in the doc? In-memory Delete operation fails with active DataCache -- Key: OPENJPA-35 URL: https://issues.apache.org/jira/browse/OPENJPA-35 Project: OpenJPA Issue Type: Bug Components: datacache, query Environment: Only happens when DataCache is active property name=openjpa.DataCache value=true/ property name=openjpa.RemoteCommitProvider value=sjvm/ Reporter: Pinaki Poddar Priority: Critical Attachments: openjpa-35.test.zip, openjpa-35.trace.txt Delete through query such as Query query = em.createQuery(DELETE FROM Node n); query.executeUpdate(); fails with following exception (only when DataCache is active) Exception in thread main 4|false|0.0.0 org.apache.openjpa.persistence.ArgumentException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1029) at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeDelete(ExpressionStoreQuery.java:665) at org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeDelete(QueryCacheStoreQuery.java:348) at org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1012) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:768) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:831) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:827) at org.apache.openjpa.kernel.DelegatingQuery.deleteAll(DelegatingQuery.java:544) at org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:299) at control.Test.clear(Test.java:87) at control.Test.run(Test.java:37) at control.Test.main(Test.java:178) Caused by: java.lang.ClassCastException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:651) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:949) at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1018) ... 11 more -- 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.
[ 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=revrev=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] 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.
[ 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.
[
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] 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.
[ 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] 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.
[ 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] Updated: (OPENJPA-147) T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface
[ https://issues.apache.org/jira/browse/OPENJPA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-147: -- Attachment: IPerson.java The Java interface definition is attached. I did not use an orm.xml. T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface - Key: OPENJPA-147 URL: https://issues.apache.org/jira/browse/OPENJPA-147 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Pinaki Poddar Attachments: iface.trace.1.txt, iface.trace.2.txt, iface.trace.3.txt, iface.trace.4.txt, IPerson.java, TestInterface.java According to JavaDoc, OpenJPAEntityManager.createInstance() method public T T createInstance(ClassT cls); behaves as follows: Create a new instance of type codecls/code. If codecls/code is an interface or an abstract class whose abstract methods follow the JavaBeans convention, this method will create a concrete implementation according to the metadata that defines the class The method fails when T is an interface. The failure may be due to incorrect user configuration, however, further information on this extension method is not available in OpenJPA documentation. Firstly, how to specify metadata for a interface that has bean-style methods? Possibilities are: a) Annotating the Java interface definition with @Entity b) Specifying in classorg.acme.IPerson/class in persistence.xml Either of the above fails. a) fails at parsing b) fails with no metadata There may be a correct but undocumented way of specifying a managed interface. If that is the case, then this JIRA report should be treated as a documentation bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-147) T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface
[ https://issues.apache.org/jira/browse/OPENJPA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-147: -- Attachment: iface.trace.1.txt T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface - Key: OPENJPA-147 URL: https://issues.apache.org/jira/browse/OPENJPA-147 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Pinaki Poddar Attachments: iface.trace.1.txt, iface.trace.2.txt, iface.trace.3.txt, iface.trace.4.txt According to JavaDoc, OpenJPAEntityManager.createInstance() method public T T createInstance(ClassT cls); behaves as follows: Create a new instance of type codecls/code. If codecls/code is an interface or an abstract class whose abstract methods follow the JavaBeans convention, this method will create a concrete implementation according to the metadata that defines the class The method fails when T is an interface. The failure may be due to incorrect user configuration, however, further information on this extension method is not available in OpenJPA documentation. Firstly, how to specify metadata for a interface that has bean-style methods? Possibilities are: a) Annotating the Java interface definition with @Entity b) Specifying in classorg.acme.IPerson/class in persistence.xml Either of the above fails. a) fails at parsing b) fails with no metadata There may be a correct but undocumented way of specifying a managed interface. If that is the case, then this JIRA report should be treated as a documentation bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-147) T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface
[ https://issues.apache.org/jira/browse/OPENJPA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-147: -- Attachment: iface.trace.2.txt T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface - Key: OPENJPA-147 URL: https://issues.apache.org/jira/browse/OPENJPA-147 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Pinaki Poddar Attachments: iface.trace.1.txt, iface.trace.2.txt, iface.trace.3.txt, iface.trace.4.txt According to JavaDoc, OpenJPAEntityManager.createInstance() method public T T createInstance(ClassT cls); behaves as follows: Create a new instance of type codecls/code. If codecls/code is an interface or an abstract class whose abstract methods follow the JavaBeans convention, this method will create a concrete implementation according to the metadata that defines the class The method fails when T is an interface. The failure may be due to incorrect user configuration, however, further information on this extension method is not available in OpenJPA documentation. Firstly, how to specify metadata for a interface that has bean-style methods? Possibilities are: a) Annotating the Java interface definition with @Entity b) Specifying in classorg.acme.IPerson/class in persistence.xml Either of the above fails. a) fails at parsing b) fails with no metadata There may be a correct but undocumented way of specifying a managed interface. If that is the case, then this JIRA report should be treated as a documentation bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-147) T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface
[ https://issues.apache.org/jira/browse/OPENJPA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar updated OPENJPA-147: -- Attachment: TestInterface.java T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface - Key: OPENJPA-147 URL: https://issues.apache.org/jira/browse/OPENJPA-147 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Pinaki Poddar Attachments: iface.trace.1.txt, iface.trace.2.txt, iface.trace.3.txt, iface.trace.4.txt, TestInterface.java According to JavaDoc, OpenJPAEntityManager.createInstance() method public T T createInstance(ClassT cls); behaves as follows: Create a new instance of type codecls/code. If codecls/code is an interface or an abstract class whose abstract methods follow the JavaBeans convention, this method will create a concrete implementation according to the metadata that defines the class The method fails when T is an interface. The failure may be due to incorrect user configuration, however, further information on this extension method is not available in OpenJPA documentation. Firstly, how to specify metadata for a interface that has bean-style methods? Possibilities are: a) Annotating the Java interface definition with @Entity b) Specifying in classorg.acme.IPerson/class in persistence.xml Either of the above fails. a) fails at parsing b) fails with no metadata There may be a correct but undocumented way of specifying a managed interface. If that is the case, then this JIRA report should be treated as a documentation bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection Key: OPENJPA-117 URL: https://issues.apache.org/jira/browse/OPENJPA-117 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Priority: Minor Currently TransactionListeners can be added/removed to a broker but the list of transaction listeners registered to a particular broker is not available. Such a collection can be made available in read-only mode so a caller can determine whether to add a new listener or not, or whether a particular listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468719 ] Pinaki Poddar commented on OPENJPA-117: --- The use case is the code that intends to register a listener but gets the PersistenceManager/EntityManager from another layer outside of its own control. Then the registerer does not know whether the obtained PM/EM is already carrying a particular listener or not. Currently the internal collection of listener is not a Set, so unconditionally adding a listener results in duplicates. Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection Key: OPENJPA-117 URL: https://issues.apache.org/jira/browse/OPENJPA-117 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Priority: Minor Currently TransactionListeners can be added/removed to a broker but the list of transaction listeners registered to a particular broker is not available. Such a collection can be made available in read-only mode so a caller can determine whether to add a new listener or not, or whether a particular listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-109) every NativeQuery using SqlResultSetMapping fails at runtime with There is no query result mapping for null with name xxx when the entity is persisted in a differen
[ https://issues.apache.org/jira/browse/OPENJPA-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467492 ] Pinaki Poddar commented on OPENJPA-109: --- Will you please attach a test case + annotated domain classes or domain classes + xml descriptors. This will help us to reproduce this failure as the test cases (within Kodo test corpus) for SQLResultMapping and SQLResultSetMappings that are based on the same implementation are not showing similar failure. every NativeQuery using SqlResultSetMapping fails at runtime with There is no query result mapping for null with name xxx when the entity is persisted in a different method than the method doing the query. --- Key: OPENJPA-109 URL: https://issues.apache.org/jira/browse/OPENJPA-109 Project: OpenJPA Issue Type: Bug Environment: windows xp, openjpa_097_incubating Reporter: George Hongell every NativeQuery using SqlResultSetMapping fails at runtime with There is no query result mapping for null with name xxx when the entity is persisted in a different method than the method doing the query. 4|true|0.9.7-incubating-SNAPSHOT org.apache.openjpa.persistence.ArgumentException: There is no query result mapping for null with name DeptBeanMapping. at org.apache.openjpa.jdbc.meta.MappingRepository.getQueryResultMapping(MappingRepository.java:175) at org.apache.openjpa.jdbc.kernel.SQLStoreQuery$SQLExecutor.init(SQLStoreQuery.java:174) at org.apache.openjpa.jdbc.kernel.SQLStoreQuery.newDataStoreExecutor(SQLStoreQuery.java:143) at org.apache.openjpa.kernel.QueryImpl.createExecutor(QueryImpl.java:718) at org.apache.openjpa.kernel.QueryImpl.compileForDataStore(QueryImpl.java:676) at org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:658) at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1463) at org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:120) at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:214) at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:264) at com.ibm.ws.query.tests.JUNamedNativeQueryTest.testSelectDeptBean(JUNamedNativeQueryTest.java:457) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(Unknown Source) at junit.framework.TestCase.runBare(Unknown Source) at junit.framework.TestResult$1.protect(Unknown Source) at junit.framework.TestResult.runProtected(Unknown Source) at junit.framework.TestResult.run(Unknown Source) at junit.framework.TestCase.run(Unknown Source) at junit.framework.TestSuite.runTest(Unknown Source) at junit.framework.TestSuite.run(Unknown Source) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-60) Specifying the wrong persistence implementation in persistence.xml leads to misleading error message
[ http://issues.apache.org/jira/browse/OPENJPA-60?page=comments#action_12438249 ] Pinaki Poddar commented on OPENJPA-60: -- Fix available on revision #450632. Specifying the wrong persistence implementation in persistence.xml leads to misleading error message Key: OPENJPA-60 URL: http://issues.apache.org/jira/browse/OPENJPA-60 Project: OpenJPA Issue Type: Bug Reporter: David Ezzio Priority: Minor If kodo.persistence.PersistenceProviderImpl is specified instead of org.apache.openjpa.persistence.PersistenceProviderImpl, a misleading error message results that suggests that the persistence.xml file is missing or cannot be found. enhance: [java] Exception in thread main java.util.MissingResourceException: org.apache.openjpa.persistence.PersistenceProductDerivation:java.util.MissingResourceException: The specified XML resource META-INF/persistence.xml for persistence unit null can't be found in your class path. [java] at org.apache.openjpa.lib.conf.ProductDerivations.reportErrors(ProductDerivations.java:217) [java] at org.apache.openjpa.lib.conf.ProductDerivations.load(ProductDerivations.java:135) [java] at org.apache.openjpa.lib.conf.Configurations.populateConfiguration(Configurations.java:198) [java] at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:3468) [java] at org.apache.openjpa.enhance.PCEnhancer.main(PCEnhancer.java:3441) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
