Nabble - OpenJPA Developers

[jira] Created: (OPENJPA-1159) Bad error message for find of an Entity with compound primary key if parameter of wrong class

2009-07-03T20:54:47Z

Bad error message for find of an Entity with compound primary key if parameter of wrong class
---------------------------------------------------------------------------------------------

Key: OPENJPA-1159
URL: https://issues.apache.org/jira/browse/OPENJPA-1159
Project: OpenJPA
Issue Type: Bug
Components: kernel
Reporter: Craig Russell
Assignee: Craig Russell
Priority: Minor
Fix For: 2.0.0

Test set: com.mysql.clusterj.openjpatest.LongLongStringPKRelationshipTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.234 sec <<< FAILURE!
test(com.mysql.clusterj.openjpatest.LongLongStringPKRelationshipTest) Time elapsed: 4.168 sec <<< ERROR!
<openjpa-1.2.0-r422266:753657 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: 1
at org.apache.openjpa.kernel.BrokerImpl.newObjectId(BrokerImpl.java:1154)
at org.apache.openjpa.kernel.DelegatingBroker.newObjectId(DelegatingBroker.java:268)
at org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:451)
at com.mysql.clusterj.openjpatest.LongLongStringPKRelationshipTest.test(LongLongStringPKRelationshipTest.java:65)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at org.apache.openjpa.util.ApplicationIds$PrimaryKeyFieldManager.retrieve(ApplicationIds.java:602)
at org.apache.openjpa.util.ApplicationIds$PrimaryKeyFieldManager.fetchLongField(ApplicationIds.java:578)
at com.mysql.clusterj.jpatest.model.LongLongStringFKRelationship.pcCopyKeyFieldsToObjectId(LongLongStringFKRelationship.java)
at org.apache.openjpa.enhance.PCRegistry.copyKeyFieldsToObjectId(PCRegistry.java:172)
at org.apache.openjpa.util.ApplicationIds.fromPKValues(ApplicationIds.java:218)
at org.apache.openjpa.kernel.BrokerImpl.newObjectId(BrokerImpl.java:1141)
... 30 more

The failure is clearly a user error but the message is bad. The message should say that the type of the argument doesn't match the metadata for the class.

The failing line of code is:
LongLongStringFKRelationship b = em.find(LongLongStringFKRelationship.class, i);

The correct code is:
LongLongStringFKRelationship b = em.find(LongLongStringFKRelationship.class, new LongLongStringOid(i));

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

[jira] Updated: (OPENJPA-167) Bad error message for named queries and no listed entities

2009-07-03T20:48:47Z

[ https://issues.apache.org/jira/browse/OPENJPA-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Craig Russell updated OPENJPA-167:
----------------------------------

Priority: Blocker
Summary: Bad error message for named queries and no listed entities (was: Named queries and no listed entities: bad error message)

> Bad error message for named queries and no listed entities
> ----------------------------------------------------------
>
> Key: OPENJPA-167
> URL: https://issues.apache.org/jira/browse/OPENJPA-167
> Project: OpenJPA
> Issue Type: Bug
> Components: diagnostics
> Affects Versions: 0.9.0, 0.9.6
> Reporter: Patrick Linskey
> Priority: Blocker
>
> When executing a named query without having declared any persistent types, I get the following:
> <4|true|0.0.0> org.apache.openjpa.persistence.ArgumentException: There is no query with the name "SimpleXml.findAll" defined for any of the known persistent classes: null.
> at org.apache.openjpa.meta.MetaDataRepository.getQueryMetaData(MetaDataRepository.java:1494)
> at org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery(EntityManagerImpl.java:767)
> at org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery(EntityManagerImpl.java:62)
> at org.apache.openjpa.persistence.xml.TestSimpleXmlEntity.testNamedQueryInXmlNamedEntity(TestSimpleXmlEntity.java:12)
> This message should read "No persistent classes were listed in <path-to-persistence.xml>, and auto-class-scanning is not configured, so no named queries can be found. You can configure auto-class-scanning by <auto-class-scan info here>" or something along those lines.

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

[jira] Updated: (OPENJPA-1158) Incorrect handling of long values in AbstractResult

2009-07-03T13:20:47Z

[ https://issues.apache.org/jira/browse/OPENJPA-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Craig Russell updated OPENJPA-1158:
-----------------------------------

Patch Info: [Patch Available]

> Incorrect handling of long values in AbstractResult
> ---------------------------------------------------
>
> Key: OPENJPA-1158
> URL: https://issues.apache.org/jira/browse/OPENJPA-1158
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 2.0.0
> Reporter: Craig Russell
> Assignee: Craig Russell
> Priority: Minor
> Attachments: OPENJPA-1158.patch
>
>
> This code is in org.apache.openjpa.jdbc.sql.AbstractResult.
> public long getLong(Object obj)
> throws SQLException {
> return getLongInternal(translate(obj, null), null);
> }
> public long getLong(Column col, Joins joins)
> throws SQLException {
> return getLongInternal(translate(col, joins), joins);
> }
> protected long getLongInternal(Object obj, Joins joins)
> throws SQLException {
> Number val = (Number) checkNull(getObjectInternal(obj,
> JavaTypes.INT, null, joins));
> return (val == null) ? 0 : val.intValue();
> }
> It seems like it's an obvious bug; using intValue and JavaTypes.INT in getLongInternal should use longValue and JavaTypes.LONG.

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

[jira] Updated: (OPENJPA-1158) Incorrect handling of long values in AbstractResult

2009-07-03T13:20:47Z

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

[jira] Created: (OPENJPA-1158) Incorrect handling of long values in AbstractResult

2009-07-03T13:18:47Z

Incorrect handling of long values in AbstractResult
---------------------------------------------------

Key: OPENJPA-1158
URL: https://issues.apache.org/jira/browse/OPENJPA-1158
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects Versions: 2.0.0
Reporter: Craig Russell
Assignee: Craig Russell
Priority: Minor

This code is in org.apache.openjpa.jdbc.sql.AbstractResult.

public long getLong(Object obj)
throws SQLException {
return getLongInternal(translate(obj, null), null);
}

public long getLong(Column col, Joins joins)
throws SQLException {
return getLongInternal(translate(col, joins), joins);
}

protected long getLongInternal(Object obj, Joins joins)
throws SQLException {
Number val = (Number) checkNull(getObjectInternal(obj,
JavaTypes.INT, null, joins));
return (val == null) ? 0 : val.intValue();
}

It seems like it's an obvious bug; using intValue and JavaTypes.INT in getLongInternal should use longValue and JavaTypes.LONG.

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

Re: Bug in AbstractResult with long data types?

2009-07-03T13:09:27Z

On Jul 3, 2009, at 12:09 PM, Craig L Russell wrote:

> I've been looking at the result handling and ran across this code in
> org.apache.openjpa.jdbc.sql.AbstractResult.
>
> public long getLong(Object obj)
> throws SQLException {
> return getLongInternal(translate(obj, null), null);
> }
>
> public long getLong(Column col, Joins joins)
> throws SQLException {
> return getLongInternal(translate(col, joins), joins);
> }
>
> protected long getLongInternal(Object obj, Joins joins)
> throws SQLException {
> Number val = (Number) checkNull(getObjectInternal(obj,
> JavaTypes.INT, null, joins));
> return (val == null) ? 0 : val.intValue();
> }
>
> It seems like it's an obvious bug; using intValue and JavaTypes.INT
> in getLongInternal should use longValue and JavaTypes.LONG.
>
> 1. Is this as obvious an error as it seems to me?
>
> 2. If it is an error, why don't we see it in all of our tests that
> have long types in the domain model?

Because the JDBC classes override the getXXXInternal methods. This
method is never called.

I'll file a JIRA and fix it.

Craig

>
> Thanks,
>
> Craig
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@...
> P.S. A good JDO? O, Gasp!
>

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@...
P.S. A good JDO? O, Gasp!

smime.p7s (3K) Download Attachment

Bug in AbstractResult with long data types?

2009-07-03T12:09:16Z

I've been looking at the result handling and ran across this code in
org.apache.openjpa.jdbc.sql.AbstractResult.

public long getLong(Object obj)
throws SQLException {
return getLongInternal(translate(obj, null), null);
}

public long getLong(Column col, Joins joins)
throws SQLException {
return getLongInternal(translate(col, joins), joins);
}

protected long getLongInternal(Object obj, Joins joins)
throws SQLException {
Number val = (Number) checkNull(getObjectInternal(obj,
JavaTypes.INT, null, joins));
return (val == null) ? 0 : val.intValue();
}

It seems like it's an obvious bug; using intValue and JavaTypes.INT in
getLongInternal should use longValue and JavaTypes.LONG.

1. Is this as obvious an error as it seems to me?

2. If it is an error, why don't we see it in all of our tests that
have long types in the domain model?

Thanks,

Craig

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@...
P.S. A good JDO? O, Gasp!

smime.p7s (3K) Download Attachment

[LOGO] submission

2009-07-02T17:40:52Z

On 3/7/09 01:37, Pid wrote:
> Hope these aren't too late for inclusion.

Try again.
I re-read the instructions: PNGs attached this time. (doh)

> Cheers,
>
> Pid

[LOGO] submission

2009-07-02T17:37:39Z

Hope these aren't too late for inclusion.

Cheers,

Pid

[jira] Created: (OPENJPA-1157) Integration tests for Bean Validation providers - Part 2

2009-07-02T12:51:47Z

Integration tests for Bean Validation providers - Part 2
--------------------------------------------------------

Key: OPENJPA-1157
URL: https://issues.apache.org/jira/browse/OPENJPA-1157
Project: OpenJPA
Issue Type: Sub-task
Components: validation
Reporter: Donald Woods
Fix For: 2.0.0

Part 2 - add tests for remaining constraint types, some method constraint tests and @Valid tests

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

Re: Reason for introducing lock inside statemanagerImpl.

2009-07-02T11:47:16Z

Hi Ravi,
try (2).

the change was brought in (if memory serves me right) for the case
where multiple threads access a StateManager within a *single* broker.
This happended when SliceStoreManager spawns threads to execute database
operations. but after i made this change, i did modify further threading
model behavior for Slice threads -- so this instance-level lock to
StateManager *may be* redundant.

if you are trying (2), the multithreaded Slice tests are in slice
module.

Regards --

Pinaki

Ravi Palacherla <ravi.palacherla@...>
07/02/2009 01:00 PM

To
Pinaki Poddar <ppoddar@...>
cc
dev@...
Subject
Reason for introducing lock inside statemanagerImpl.

Hi Pinaki,

I have a question regarding lock inside statemanagerImpl.
I see that it is introduced as part of OPENJPA-825 ( r727297).
Before that change statemanager used to rely on broker’s lock.
As part of openjpa-825, a separate lock has been introduced for
statemanager.

Can you please help me understand the reason for introducing a separate
lock for statemanager.

Reason for my question :

I am working on OPENJPA-453 on trunk ; the cause of the issue on trunk is

Thread0 takes a reentrant lock inside BrokerImpl and waits to acquire
reentrant lock inside statemanagerImpl.
Thread1 takes a reentrant lock inside StatemanagerImpl and waits to
acquire reentrant lock inside BrokerImpl.
This is causing a deadlock.

Details of the issue are under:
https://issues.apache.org/jira/browse/OPENJPA-453#action_12725820

A test case demonstrating the issue is attached to the same JIRA (
OPENJPA-453_trunk_testcase.patch).

There are two fixes I can think of to avoid the above issue:

1) To obtain broker’s lock before obtaining SM’s lock inside
StateManagerImpl.lock()
Here is an svn diff for this fix.

Index:
openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateManagerImpl.java
===================================================================
---
openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateManagerImpl.java
(revision 790413)
+++
openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateManagerImpl.java
(working copy)
@@ -3248,16 +3248,20 @@
* Lock the state manager if the multithreaded option is set.
*/
protected void lock() {
- if (_instanceLock != null)
+ if (_instanceLock != null) {
+ _broker.lock();
_instanceLock.lock();
+ }
}

/**
* Unlock the state manager.
*/
protected void unlock () {
- if (_instanceLock != null)
- _instanceLock.unlock();
+ if (_instanceLock != null) {
+ _instanceLock.unlock();
+ _broker.unlock();
+ }
}

private void writeObject(ObjectOutputStream oos) throws IOException {

2) Second is to go back to the original locking mechanism , that is
statemanger will use broker’s lock.

Code for SM’s lock and unlock will be:

protected void lock() {
_broker.lock();
}

protected void unlock () {
_broker.unlock ();
}

Before deciding on which path to take, I thought I have to understand the
reason for introducing separate lock for statemanagerImpl.

Thanks in advance,
Ravi.

Reason for introducing lock inside statemanagerImpl.

2009-07-02T11:00:16Z

Hi Pinaki,

I have a question regarding lock inside statemanagerImpl.

I see that it is introduced as part of HYPERLINK "https://issues.apache.org/jira/browse/OPENJPA-825"OPENJPA-825 ( r727297).

Before that change statemanager used to rely on broker's lock.

As part of openjpa-825, a separate lock has been introduced for statemanager.

Can you please help me understand the reason for introducing a separate lock for statemanager.

Reason for my question :

I am working on OPENJPA-453 on trunk ; the cause of the issue on trunk is

Thread0 takes a reentrant lock inside BrokerImpl and waits to acquire reentrant lock inside statemanagerImpl.
Thread1 takes a reentrant lock inside StatemanagerImpl and waits to acquire reentrant lock inside BrokerImpl.

This is causing a deadlock.

Details of the issue are under:

https://issues.apache.org/jira/browse/OPENJPA-453#action_12725820

A test case demonstrating the issue is attached to the same JIRA (HYPERLINK "https://issues.apache.org/jira/secure/attachment/12412408/OPENJPA-453_trunk_testcase.patch"OPENJPA-453_trunk_testcase.patch).

There are two fixes I can think of to avoid the above issue:

1) To obtain broker's lock before obtaining SM's lock inside StateManagerImpl.lock()

Here is an svn diff for this fix.

Index: openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateManagerImpl.java

===================================================================

--- openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateManagerImpl.java (revision 790413)

+++ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateManagerImpl.java (working copy)

@@ -3248,16 +3248,20 @@

* Lock the state manager if the multithreaded option is set.

*/

protected void lock() {

- if (_instanceLock != null)

+ if (_instanceLock != null) {

+ _broker.lock();

_instanceLock.lock();

+ }

}

/**

* Unlock the state manager.

*/

protected void unlock () {

- if (_instanceLock != null)

- _instanceLock.unlock();

+ if (_instanceLock != null) {

+ _instanceLock.unlock();

+ _broker.unlock();

+ }

}

private void writeObject(ObjectOutputStream oos) throws IOException {

2) Second is to go back to the original locking mechanism , that is statemanger will use broker's lock.

Code for SM's lock and unlock will be:

protected void lock() {

_broker.lock();

}

protected void unlock () {

_broker.unlock ();

}

Before deciding on which path to take, I thought I have to understand the reason for introducing separate lock for statemanagerImpl.

Thanks in advance,

Ravi.

[jira] Created: (OPENJPA-1156) Path length issues on Windows

2009-07-02T09:53:47Z

Path length issues on Windows
------------------------------

Key: OPENJPA-1156
URL: https://issues.apache.org/jira/browse/OPENJPA-1156
Project: OpenJPA
Issue Type: Bug
Components: build / infrastructure
Affects Versions: 1.2.2, 1.3.0, 2.0.0
Reporter: Michael Dick
Assignee: Michael Dick

The testcases for OPENJPA-1061 exceed the maximum path length on Windows. The problem was reported from a continuous integration server which actually complained about the svn files, but it could happen for "normal" builds as well.

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

Re: Message for commit on behalf of someone should be informative

2009-07-02T09:57:32Z

Here are the ASF suggested guidelines -

http://www.apache.org/dev/committers.html#applying-patches

"You need to make sure that the commit message contains at least the
name of the contributor and ideally a reference to the Bugzilla or JIRA
issue where the patch was submitted. The reasons: this preserves the
legal trail and makes sure that contributors are recognized. Obviously,
the latter doesn't mean it's not a good idea to list the names of all
contributors somewhere on the website. To make it easier to "grep" for
commits with patches from contributors, always use the same pattern in
the commit message. Traditionally, we use "Submitted by: <name>" or
"Obtained from: <name>"."

Personally, I like to use the "contributed by" text, but don't care what
format people use, as long as the contributors name is included.

-Donald

Personally, I don't care as long as

Pinaki Poddar wrote:

> Hi,
> I notice commit comments like this
> "OPENJPA-NNN: Commiting patch contributed by XXX YYY"
>
> Now this message is not helpful in retrospect. The message should be
> "OPENJPA-NNN: Change for this or that. Committing on behalf of XXX YYY."
>
>
> -----
> Pinaki

Message for commit on behalf of someone should be informative

2009-07-02T08:50:01Z

Hi,
I notice commit comments like this
"OPENJPA-NNN: Commiting patch contributed by XXX YYY"

Now this message is not helpful in retrospect. The message should be
"OPENJPA-NNN: Change for this or that. Committing on behalf of XXX YYY."

Pinaki

[jira] Commented: (OPENJPA-1155) BrokerImpl.detachAllInternal() does not detach newly loaded entities

2009-07-02T10:03:47Z

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

Dianne Richards commented on OPENJPA-1155:
------------------------------------------

I forgot to mention when I attached the patch - The original problem that caused this was in a container with a client-server application. I wasn't able to re-create this problem in a JSE environment, so I'm not able to provide junit tests.

> BrokerImpl.detachAllInternal() does not detach newly loaded entities
> --------------------------------------------------------------------
>
> Key: OPENJPA-1155
> URL: https://issues.apache.org/jira/browse/OPENJPA-1155
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Fix For: 2.0.0
>
> Attachments: patch.txt
>
>
> During detach, it is possible for additional entities to be loaded if the openjpa.DetachState property has been set to "all" or "fetch-groups". These entities may not be included in the collection of entities that are identified in the BrokerImpl.detachAllInternal() method when it calls the DetachManager.detachAll(collection) method. Before 2.0, these newly loaded entities were always detached since the detach processing always cascaded. However, with the 2.0 spec requirements for cascade, the default behavior no longer cascades. Therefore, there may be some entities left in the persistence context after this processing occurs. detachAllInternal() is associated with the clear(), close(), and afterCompletion() operations and it is expected that the persistence context really be empty. To ensure this, the compatibility option of cascadeWithDetach will be set to true by detachAllInternal() before calling the DetachManager.detach() method.

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

[jira] Updated: (OPENJPA-1155) BrokerImpl.detachAllInternal() does not detach newly loaded entities

2009-07-02T09:59:47Z

[ https://issues.apache.org/jira/browse/OPENJPA-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Donald Woods updated OPENJPA-1155:
----------------------------------

Patch Info: [Patch Available]

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

[jira] Updated: (OPENJPA-1155) BrokerImpl.detachAllInternal() does not detach newly loaded entities

2009-07-02T08:57:47Z

[ https://issues.apache.org/jira/browse/OPENJPA-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dianne Richards updated OPENJPA-1155:
-------------------------------------

Attachment: patch.txt

Attaching patch with the fix described in the previous comment.

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

[jira] Assigned: (OPENJPA-1155) BrokerImpl.detachAllInternal() does not detach newly loaded entities

2009-07-02T08:43:47Z

[ https://issues.apache.org/jira/browse/OPENJPA-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dianne Richards reassigned OPENJPA-1155:
----------------------------------------

Assignee: Dianne Richards

> BrokerImpl.detachAllInternal() does not detach newly loaded entities
> --------------------------------------------------------------------
>
> Key: OPENJPA-1155
> URL: https://issues.apache.org/jira/browse/OPENJPA-1155
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Fix For: 2.0.0
>
>
> During detach, it is possible for additional entities to be loaded if the openjpa.DetachState property has been set to "all" or "fetch-groups". These entities may not be included in the collection of entities that are identified in the BrokerImpl.detachAllInternal() method when it calls the DetachManager.detachAll(collection) method. Before 2.0, these newly loaded entities were always detached since the detach processing always cascaded. However, with the 2.0 spec requirements for cascade, the default behavior no longer cascades. Therefore, there may be some entities left in the persistence context after this processing occurs. detachAllInternal() is associated with the clear(), close(), and afterCompletion() operations and it is expected that the persistence context really be empty. To ensure this, the compatibility option of cascadeWithDetach will be set to true by detachAllInternal() before calling the DetachManager.detach() method.

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

[jira] Work started: (OPENJPA-1155) BrokerImpl.detachAllInternal() does not detach newly loaded entities

2009-07-02T08:43:47Z

[ https://issues.apache.org/jira/browse/OPENJPA-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on OPENJPA-1155 started by Dianne Richards.

> BrokerImpl.detachAllInternal() does not detach newly loaded entities
> --------------------------------------------------------------------
>
> Key: OPENJPA-1155
> URL: https://issues.apache.org/jira/browse/OPENJPA-1155
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Dianne Richards
> Assignee: Dianne Richards
> Fix For: 2.0.0
>
>
> During detach, it is possible for additional entities to be loaded if the openjpa.DetachState property has been set to "all" or "fetch-groups". These entities may not be included in the collection of entities that are identified in the BrokerImpl.detachAllInternal() method when it calls the DetachManager.detachAll(collection) method. Before 2.0, these newly loaded entities were always detached since the detach processing always cascaded. However, with the 2.0 spec requirements for cascade, the default behavior no longer cascades. Therefore, there may be some entities left in the persistence context after this processing occurs. detachAllInternal() is associated with the clear(), close(), and afterCompletion() operations and it is expected that the persistence context really be empty. To ensure this, the compatibility option of cascadeWithDetach will be set to true by detachAllInternal() before calling the DetachManager.detach() method.

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

[jira] Created: (OPENJPA-1155) BrokerImpl.detachAllInternal() does not detach newly loaded entities

2009-07-02T08:41:47Z

BrokerImpl.detachAllInternal() does not detach newly loaded entities
--------------------------------------------------------------------

Key: OPENJPA-1155
URL: https://issues.apache.org/jira/browse/OPENJPA-1155
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 2.0.0
Reporter: Dianne Richards
Fix For: 2.0.0

During detach, it is possible for additional entities to be loaded if the openjpa.DetachState property has been set to "all" or "fetch-groups". These entities may not be included in the collection of entities that are identified in the BrokerImpl.detachAllInternal() method when it calls the DetachManager.detachAll(collection) method. Before 2.0, these newly loaded entities were always detached since the detach processing always cascaded. However, with the 2.0 spec requirements for cascade, the default behavior no longer cascades. Therefore, there may be some entities left in the persistence context after this processing occurs. detachAllInternal() is associated with the clear(), close(), and afterCompletion() operations and it is expected that the persistence context really be empty. To ensure this, the compatibility option of cascadeWithDetach will be set to true by detachAllInternal() before calling the DetachManager.detach() method.

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

[jira] Updated: (OPENJPA-1154) use of getFetchPlan().setMaxDepth(x) puts DISTINCT in the SQL

2009-07-01T12:47:47Z

[ https://issues.apache.org/jira/browse/OPENJPA-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

B.J. Reed updated OPENJPA-1154:
-------------------------------

Attachment: TestFetchPlanDepth.java

> use of getFetchPlan().setMaxDepth(x) puts DISTINCT in the SQL
> -------------------------------------------------------------
>
> Key: OPENJPA-1154
> URL: https://issues.apache.org/jira/browse/OPENJPA-1154
> Project: OpenJPA
> Issue Type: Improvement
> Components: sql
> Affects Versions: 2.0.0
> Environment: DB2 and Windows
> Reporter: B.J. Reed
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: TestFetchPlanDepth.java
>
>
> Use of q.getFetchPlan().setMaxFetchDepth(x); // x is any depth
> will always add DISTINCT to the generated SQL. Seems like the DISTINCT shouldn't be added.

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

[jira] Created: (OPENJPA-1154) use of getFetchPlan().setMaxDepth(x) puts DISTINCT in the SQL

2009-07-01T12:41:47Z

use of getFetchPlan().setMaxDepth(x) puts DISTINCT in the SQL
-------------------------------------------------------------

Key: OPENJPA-1154
URL: https://issues.apache.org/jira/browse/OPENJPA-1154
Project: OpenJPA
Issue Type: Improvement
Components: sql
Affects Versions: 2.0.0
Environment: DB2 and Windows
Reporter: B.J. Reed
Priority: Minor
Fix For: 2.0.0

Use of q.getFetchPlan().setMaxFetchDepth(x); // x is any depth
will always add DISTINCT to the generated SQL. Seems like the DISTINCT shouldn't be added.

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

[jira] Created: (OPENJPA-1153) Test suite speed-up outside SingleEMFTestCase

2009-07-01T10:59:47Z

Test suite speed-up outside SingleEMFTestCase
---------------------------------------------

Key: OPENJPA-1153
URL: https://issues.apache.org/jira/browse/OPENJPA-1153
Project: OpenJPA
Issue Type: Test
Affects Versions: 1.2.1, 1.1.0
Reporter: Milosz Tylenda
Assignee: Milosz Tylenda
Priority: Minor

From the developer list [1]:

We have groups of tests which do not inherit from SingleEMFTestCase and use common persistence.xml files to do their setUp()s. Each persistence.xml contains all entities used by the group. An individual test uses its group's persistence.xml to set itself up although the test usually uses one or two entities. Not surprisingly getting database metadata and issuing DELETE TABLE statements often takes much more time than the actual test itself.

The most notable example is a group of tests located in openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/kernel/. Their openjpa-persistence-jdbc/src/test/resources/org/apache/openjpa/persistence/kernel/common/apps/META-INF/persistence.xml contains almost 100 entities. I measured how long does it take to run TestDateQueries which uses only one entity but sets itself up with that persistence xml. I ran the test suite with -Dtest=TestDateQueries and the necessary tables were already in the database:

- Derby: 20 secs
- MySQL: 12 secs
- PostgreSQL: 46 secs

Then I modified the persistence.xml to include only the entity used by the test. The timings for all databases dropped to around 4 seconds.

My idea is to modify these tests (at least the ones taking the most time) and their superclass(-es) to not use persistence.xml but specify used entities as setUp() parameters, similarly to what SingleEMFTestCase. It looks like we would save at least a few minutes on a test suite run.

[1] http://n2.nabble.com/Test-suite-speed-up-outside-SingleEMFTestCase-td3169383.html

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

[jira] Created: (OPENJPA-1152) OpenJPA 2.0 iteration 9 primary task

2009-07-01T07:59:47Z

OpenJPA 2.0 iteration 9 primary task
------------------------------------

Key: OPENJPA-1152
URL: https://issues.apache.org/jira/browse/OPENJPA-1152
Project: OpenJPA
Issue Type: New Feature
Components: jpa
Affects Versions: 2.0.0
Reporter: Jeremy Bauer
Assignee: Jeremy Bauer

This is the parent task for OpenJPA iteration 9. The iteration 9 development period is from July 6th - July 31st. Features to be completed during this iteration must be assigned as a subtask to this task. The JPA 2.0 Roadmap [1] will contain iteration 9 features and tracking information.

[1] http://cwiki.apache.org/confluence/display/openjpa/JPA+2.0+Roadmap

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

[jira] Updated: (OPENJPA-1151) Cache the current-time timestamp in AbstractQueryCache.onTypesChanged()

2009-07-01T12:59:47Z

> Cache the current-time timestamp in AbstractQueryCache.onTypesChanged()
> -----------------------------------------------------------------------
>
> Key: OPENJPA-1151
> URL: https://issues.apache.org/jira/browse/OPENJPA-1151
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Reporter: Jody Grassel
> Priority: Trivial
> Attachments: OpenJPA-trunk-JIRA1151-tests.patch, OpenJPA-trunk-JIRA1151.patch
>
>
> AbstractQueryCache.java contains the following block:
> for (Object o: changedTypes) {
> String name = ((Class) o).getName();
> if(!changedClasses.containsKey(name))
> changedClasses.put(name,
> new Long(System.currentTimeMillis()));
> }
> Suggesting caching the Long containing the entity type's last-modification timestamp outside of the for-loop to improve performance and reduce memory usage.

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

[jira] Commented: (OPENJPA-1151) Cache the current-time timestamp in AbstractQueryCache.onTypesChanged()

2009-07-01T08:13:47Z

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

Jody Grassel commented on OPENJPA-1151:
---------------------------------------

It looks like the class TestQueryTimestampEviction had changed since r708980. I'll make the necessary adjustments and resubmit.

> Cache the current-time timestamp in AbstractQueryCache.onTypesChanged()
> -----------------------------------------------------------------------
>
> Key: OPENJPA-1151
> URL: https://issues.apache.org/jira/browse/OPENJPA-1151
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Reporter: Jody Grassel
> Priority: Trivial
> Attachments: OpenJPA-trunk-JIRA1151.patch
>
>
> AbstractQueryCache.java contains the following block:
> for (Object o: changedTypes) {
> String name = ((Class) o).getName();
> if(!changedClasses.containsKey(name))
> changedClasses.put(name,
> new Long(System.currentTimeMillis()));
> }
> Suggesting caching the Long containing the entity type's last-modification timestamp outside of the for-loop to improve performance and reduce memory usage.

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

[jira] Commented: (OPENJPA-1151) Cache the current-time timestamp in AbstractQueryCache.onTypesChanged()

2009-06-30T16:56:47Z

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

Michael Dick commented on OPENJPA-1151:
---------------------------------------

I'm not sure about the testcases included in the patch - they didn't merge cleanly for me. I have committed the timestamp caching portion of the fix though.

> Cache the current-time timestamp in AbstractQueryCache.onTypesChanged()
> -----------------------------------------------------------------------
>
> Key: OPENJPA-1151
> URL: https://issues.apache.org/jira/browse/OPENJPA-1151
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Reporter: Jody Grassel
> Priority: Trivial
> Attachments: OpenJPA-trunk-JIRA1151.patch
>
>
> AbstractQueryCache.java contains the following block:
> for (Object o: changedTypes) {
> String name = ((Class) o).getName();
> if(!changedClasses.containsKey(name))
> changedClasses.put(name,
> new Long(System.currentTimeMillis()));
> }
> Suggesting caching the Long containing the entity type's last-modification timestamp outside of the for-loop to improve performance and reduce memory usage.

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

[jira] Updated: (OPENJPA-1151) Cache the current-time timestamp in AbstractQueryCache.onTypesChanged()

2009-06-30T14:22:48Z

[ https://issues.apache.org/jira/browse/OPENJPA-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jody Grassel updated OPENJPA-1151:
----------------------------------

Attachment: OpenJPA-trunk-JIRA1151.patch

Added a patch that caches the Long containing the current time used for cataloging when an entity type is modified for the timestamp query cache eviction policy.

Added more testing for default and timestamp query cache eviction policies.

> Cache the current-time timestamp in AbstractQueryCache.onTypesChanged()
> -----------------------------------------------------------------------
>
> Key: OPENJPA-1151
> URL: https://issues.apache.org/jira/browse/OPENJPA-1151
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Reporter: Jody Grassel
> Priority: Trivial
> Attachments: OpenJPA-trunk-JIRA1151.patch
>
>
> AbstractQueryCache.java contains the following block:
> for (Object o: changedTypes) {
> String name = ((Class) o).getName();
> if(!changedClasses.containsKey(name))
> changedClasses.put(name,
> new Long(System.currentTimeMillis()));
> }
> Suggesting caching the Long containing the entity type's last-modification timestamp outside of the for-loop to improve performance and reduce memory usage.

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

[jira] Created: (OPENJPA-1151) Cache the current-time timestamp in AbstractQueryCache.onTypesChanged()

2009-06-30T14:18:47Z

Cache the current-time timestamp in AbstractQueryCache.onTypesChanged()
-----------------------------------------------------------------------

Key: OPENJPA-1151
URL: https://issues.apache.org/jira/browse/OPENJPA-1151
Project: OpenJPA
Issue Type: Improvement
Components: jdbc
Reporter: Jody Grassel
Priority: Trivial

AbstractQueryCache.java contains the following block:

for (Object o: changedTypes) {
String name = ((Class) o).getName();
if(!changedClasses.containsKey(name))
changedClasses.put(name,
new Long(System.currentTimeMillis()));
}

Suggesting caching the Long containing the entity type's last-modification timestamp outside of the for-loop to improve performance and reduce memory usage.

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

[jira] Created: (OPENJPA-1150) Add WriteBehind mode to cache updates before flushing to backing store

2009-06-30T13:10:48Z

Add WriteBehind mode to cache updates before flushing to backing store
----------------------------------------------------------------------

Key: OPENJPA-1150
URL: https://issues.apache.org/jira/browse/OPENJPA-1150
Project: OpenJPA
Issue Type: New Feature
Components: kernel
Affects Versions: 2.0.0
Reporter: Michael Dick
Assignee: Michael Dick
Fix For: 2.0.0

The current L2 / DataCache implementation is exhibits write-through behavior. When an entity is updated its contents are updated in the datacache and then flushed to the backing store when the transaction completes.

This feature will enable write-behind behavior - instead of updating the backing store when the transaction completes, the updates will be cached in memory until until triggered to truly flush. This approach has the effect of reducing the load on the backing store and (hopefully) improving overall throughput.

Naturally there are some caveats to this approach.

1. A DataCache must be used in conjunction with the WriteBehind cache. The DataCache will be kept in sync with the WriteBehind cache reducing the possibility of stale reads.
2. When operating in write-behind mode you need to take care that OpenJPA is the only application accessing these rows. Updates from other applications may lead to errors when the write-behind cache is flushed.
2a. Some care must be taken when running on multiple JVMs. The DataCache & WriteBehindCache need to be kept in sync across JVMs. The DataCache has some capability in this area and the WriteBehindCache will further extend that.
2b. The application must contain some logic to recover from a failed update.
3. Database generated columns (ie IDENTITY, SEQUENCE) will not work correctly (at least not with the initial version of write-behind)
3a. Table generated columns will work, but the SQL used to obtain the value from the table will bypass the WriteBehindCache (ie you may see some database traffic in this case).

This support may not be suitable for every application. Write heavy applications will see great benefit as will applications which place high load on the database. The feature should not be enabled by default and should be considered strictly optional.

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

[jira] Updated: (OPENJPA-1149) Add embeddables sample to the examples module

2009-06-30T08:01:47Z

[ https://issues.apache.org/jira/browse/OPENJPA-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Curtis updated OPENJPA-1149:
---------------------------------

Attachment: OPENJPA-1149.patch

This patch includes all of the embeddables sample code.

> Add embeddables sample to the examples module
> ---------------------------------------------
>
> Key: OPENJPA-1149
> URL: https://issues.apache.org/jira/browse/OPENJPA-1149
> Project: OpenJPA
> Issue Type: Improvement
> Components: samples
> Affects Versions: 2.0.0
> Reporter: Rick Curtis
> Assignee: Rick Curtis
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: OPENJPA-1149.patch
>
>
> I have created a new sample uses some of the embeddables support that was added for the 2.0 spec.

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

[jira] Updated: (OPENJPA-1149) Add embeddables sample to the examples module

2009-06-30T08:01:47Z

[ https://issues.apache.org/jira/browse/OPENJPA-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Curtis updated OPENJPA-1149:
---------------------------------

Patch Info: [Patch Available]
Assignee: (was: Rick Curtis)

> Add embeddables sample to the examples module
> ---------------------------------------------
>
> Key: OPENJPA-1149
> URL: https://issues.apache.org/jira/browse/OPENJPA-1149
> Project: OpenJPA
> Issue Type: Improvement
> Components: samples
> Affects Versions: 2.0.0
> Reporter: Rick Curtis
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: OPENJPA-1149.patch
>
>
> I have created a new sample uses some of the embeddables support that was added for the 2.0 spec.

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

[jira] Assigned: (OPENJPA-1149) Add embeddables sample to the examples module

2009-06-29T14:12:49Z

[ https://issues.apache.org/jira/browse/OPENJPA-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Curtis reassigned OPENJPA-1149:
------------------------------------

Assignee: Rick Curtis

> Add embeddables sample to the examples module
> ---------------------------------------------
>
> Key: OPENJPA-1149
> URL: https://issues.apache.org/jira/browse/OPENJPA-1149
> Project: OpenJPA
> Issue Type: Improvement
> Components: samples
> Affects Versions: 2.0.0
> Reporter: Rick Curtis
> Assignee: Rick Curtis
> Priority: Minor
> Fix For: 2.0.0
>
>
> I have created a new sample uses some of the embeddables support that was added for the 2.0 spec.

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

[jira] Created: (OPENJPA-1149) Add embeddables sample to the examples module

2009-06-29T13:34:47Z

Add embeddables sample to the examples module
---------------------------------------------

Key: OPENJPA-1149
URL: https://issues.apache.org/jira/browse/OPENJPA-1149
Project: OpenJPA
Issue Type: Improvement
Components: samples
Affects Versions: 2.0.0
Reporter: Rick Curtis
Priority: Minor
Fix For: 2.0.0

I have created a new sample uses some of the embeddables support that was added for the 2.0 spec.

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