Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Reply-To: <cnd@cndavies.com>
From: "C N Davies" <cnd@cndavies.com>
To: "'Kevin Sutter'" <kwsutter@gmail.com>,
	<users@openjpa.apache.org>
References: <016101cafb54$7c5f1070$751d3150$@com>
	 <E0529A8FFC2C9143A5F1BB9A89101D0609704DF3@BD01MSXMB018.US.Cingular.Net>
	 <017401cafb59$8b33cf50$a19b6df0$@com>
 <AANLkTimQuGcx1uI1b0L4wjtc1TrqXV7U3hAKy_8etRHX@mail.gmail.com>
In-Reply-To: <AANLkTimQuGcx1uI1b0L4wjtc1TrqXV7U3hAKy_8etRHX@mail.gmail.com>
Subject: RE: OpenJPA confusing classes
Date: Tue, 25 May 2010 02:55:21 +1000
Organization: C N Davies Pty Ltd
Message-ID: <017e01cafb61$e9c40e60$bd4c2b20$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_017F_01CAFBB5.BB701E60"
Thread-Index: Acr7XXUurX5uWGr2Qqy2MYV3x8Ae6AABAwZg
Content-Language: en-au

------=_NextPart_000_017F_01CAFBB5.BB701E60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Kevin,

 
I have L2 disabled as it has been too problematic for me, so it looks like
the issue is in the L1 cache.  I don't have a test case  I can send out yet
since I'm up at 3am in the morning trying to sort out JPA issues, yet again.


Chris

 
From: Kevin Sutter [mailto:kwsutter@gmail.com] 
Sent: Tuesday, 25 May 2010 2:23 AM
To: users@openjpa.apache.org; cnd@cndavies.com
Subject: Re: OpenJPA confusing classes

 
Hi Chris,
This isn't good if the exact same code was working okay in 1.2.2 and it's
not now.  Now that the configuration and usage of the L2 cache is defined by
the spec, there may be an inconsistency that needs to be resolved.  Do you
have the L2 DataCache enabled?  It's off by default.

Or, are you referring to the Persistence Context cache (also known as the L1
cache)?

How much have you been able to debug this problem in order to narrow down
the source?  You mention the "cache", but I'm not sure which one you are
referring to.  Your scenario looks pretty straight forward.  Have you been
able to create a simple testcase to demonstrate the problem?  Any
suggestions for resolution?

Thanks,
Kevin

On Mon, May 24, 2010 at 10:55 AM, C N Davies <cnd@cndavies.com> wrote:

Well that would make sense if I wasn't using table per class. I used this
very same code in 1.2.2 with no issues but 2.0 broke it.

The DB is not enforcing this contraint, it is OpenJPA or more specifically
the cache

Chris


-----Original Message-----
From: KARR, DAVID (ATTSI) [mailto:dk068x@att.com]
Sent: Tuesday, 25 May 2010 1:33 AM
To: users@openjpa.apache.org; cnd@cndavies.com
Subject: RE: OpenJPA confusing classes

> -----Original Message-----
> From: C N Davies [mailto:cnd@cndavies.com]
> Sent: Monday, May 24, 2010 8:19 AM
> To: users@openjpa.apache.org
> Subject: OpenJPA confusing classes
>
> Here's a snippet of my ode,
>
>             (Department) es.find(Department.class, "N/A");
>
>             (PrintQueue) es.find(PrintQueue.class, "N/A");
>
> Both Department and PrintQueue entities are based upon the same super
> class
> but I use table per class so they are in separate tables.
>
> As you can see they both have the same key, but if I put the
department
> line
> 1st the find of the print queue will generate a class cast exception
> trying
> to cast a Department to a PrintQueue. If I put the PrintQueue line 1st
> I
> will get a class cast exception trying to cast a PrintQueue to  a
> Department.  The second find doesn't generate any SQL  if I have trace
> logging turned on so it looks to me that it is a cache issue.
>
> I can't see anything like this in the JIRA is it a known bug or not?

I would assume keys in an inheritance tree have to be unique across the
hierarchy.  If not, then there's no way to tell what object it really
refers to.  The CCEs are due to the fact that caching in the session
uses the PK as the key (obviously).  You already loaded a Department
with that PK, so the reference on the next line is going to load it from
the session, which blows up.

 
------=_NextPart_000_017F_01CAFBB5.BB701E60--