[jira] Commented: (OPENJPA-69) Null reference from one Entity to other causes fault with OpenJPA 0.9.0 and Apache Derby 10.1 when byte[] used as identity

[ http://issues.apache.org/jira/browse/OPENJPA-69?page=comments#action_12445525 ] Rusanov Dmitry commented on OPENJPA-69: --- Stack trace is on OpenJPA 0.9.0 (openjpa-project-0.9.0-incubating.zip) and Apache Derby 10.1.2.1 Complete stack

Re: JTA 1.1 has been published

You might ask them, but I believe that the maven folks have adopted the name space conventions of java: the java and javax groupid prefixes are reserved for the jcp; com.sun belongs to sun, com.oracle belongs to oracle, org.apache belongs to apache, etc. As long as people respect the name

RollbackException.toString()

Hi, It would seem that RollbackException's toString() doesn't print out nested exceptions by default. Is this intended? If so, is it desired behavior? -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email

RE: JTA 1.1 has been published

This is the official JTA 1.1 jar that is available at the java.net repository. +1 for using the official JTA libraries, rather than the stopgap Geronimo clones. I'll update the pom.xml unless anyone objects. +1 for moving to JTA 1.1. -Patrick

Re: RollbackException.toString()

As with all the the org.apache.openjpa.persistence.*Exception classes, it appears to defer to org.apache.openjpa.util.Exceptions.toString(ExceptionInfo), whose behavior is presumably expected. Since JDK 1.4/1.5's Throwable.toString() doesn't print out nested exception messages, I don't

Re: RollbackException.toString()

The situation I'm looking at right now, for one: I'm seeing an optimistic lock exception, and the OpenJPA exception translation is obscuring the full stack, so I just get the stack from the point of translation, rather than from the point of origin. Then the solution is to fix the exception

RE: RollbackException.toString()

The situation I'm looking at right now, for one: I'm seeing an optimistic lock exception, and the OpenJPA exception translation is obscuring the full stack, so I just get the stack from the point of translation, rather than from the point of origin. Then the solution is to fix the

massively large Assign To field in jira issue edit pages

Hi, Is there any way to dial down (or just remove) the 'Assign To' field in the jira issue edit pages? It takes *forever* (well, not quite, but nearly) to load any of the edit pages, since the page has to populate the assignment field. Thanks, -Patrick -- Patrick Linskey BEA Systems, Inc.

Re: massively large Assign To field in jira issue edit pages

Probably. But how often do you edit issues, rather than just comment or such? Maybe we need a better index in the DB? Patrick Linskey wrote: Hi, Is there any way to dial down (or just remove) the 'Assign To' field in the jira issue edit pages? It takes *forever* (well, not quite, but

Re: massively large Assign To field in jira issue edit pages

oh, figured it out All users were possible to assign to. Fixed. Patrick Linskey wrote: Hi, Is there any way to dial down (or just remove) the 'Assign To' field in the jira issue edit pages? It takes *forever* (well, not quite, but nearly) to load any of the edit pages, since the page has to

Re: RollbackException.toString()

What is this 'inner exception' that you speak of? The underlying exception is set to the cause, but the cause is not being printed. IOW, I get all the information I need when I do an e.printStackTrace() OK, that's how it should be then. I don't want to deviate from Java's standard

cached byte[] consumes excessive memory

Hi all, I am experimenting with serving blobs from a database with JPA and have noticed that, when caching is enabled, OpenJPA uses significantly more memory than you would expect to cache the blob. For example, a 7MB byte[] consumes over 120MB of memory when cached. My profiler shows me

Re: cached byte[] consumes excessive memory

Perhaps somebody else might know what is going on here? The stacktrace which produced this memory blowout is attached as a .png. http://mong.geckohosting.com.au/~roger/tmp/blob-stacktrace.png -- Ninth Avenue Software p: +61 7 3137 1351 (UTC +10) f: +61

Re: cached byte[] consumes excessive memory

AbstractPCData needs to be modified to special-case primitive arrays to just copy the array and cache it is an opaque value, rather than using a List where each element is a potentially separately-cached instance. Roger, I'd encourage you to file a JIRA issue for this problem. p.s. In

[jira] Created: (OPENJPA-70) Data caching + external modifications could result in stale data getting stuck in cache

Data caching + external modifications could result in stale data getting stuck in cache --- Key: OPENJPA-70 URL: http://issues.apache.org/jira/browse/OPENJPA-70

[jira] Resolved: (OPENJPA-70) Data caching + external modifications could result in stale data getting stuck in cache

[ http://issues.apache.org/jira/browse/OPENJPA-70?page=all ] Patrick Linskey resolved OPENJPA-70. Resolution: Fixed Resolved with 469313. Data caching + external modifications could result in stale data getting stuck in cache

Streaming database blobs

Can anybody tell me if it is possible to stream binary data from the database using JPA? I noticed in the spec, support for java.sql.Blob was removed in one of the revisions. OpenJPA, however, seems to have a few classes related to streaming binary data. Is it possible? Thanks, Roger -- View

Re: massively large Assign To field in jira issue edit pages

I don't know why the assign to field has to list all 1 jira users. Couldn't it just list the people who are allowed to be assigned issues? IIRC, only developers in the openjpa project are allowed to be assigned... Craig On Oct 30, 2006, at 3:40 PM, Geir Magnusson Jr. wrote: Probably.