Don't be afraid - it is definitely NOT JBOSS ;-)
Isn't it hibernate behind the scenes of the JBoss CMP engine?
I have been using hibernate for several years now and I'm pretty happy with
it. I'm not sure where all the RedHat/JBoss stuff is going - I assume
betting on OpenJPA/Geronimo will be a go
Hi,
I have orderline defined as LRS in Orders.In persistence.xml I have this
defined
My test program gives the above error
em.getTransaction().begin();
Query query = em.createQuery("select object(o)from Orders o where
o.o_id=3001 and o.o_d_id='02' and o.o_w_id='0005'");
List rs1 = query.get
support Java5 wildcard on OpenJPA
-
Key: OPENJPA-145
URL: https://issues.apache.org/jira/browse/OPENJPA-145
Project: OpenJPA
Issue Type: Improvement
Components: jpa, kernel
Environment: OPEN
No problem. I just thought I'd throw it up here in case it was unknown
to anyone.
Marc Prud'hommeaux wrote:
I agree that Nabble is much more navigable. I've been linking to the
mail-archives.apache.org archive just because all the examples I've
seen of posting vote results seem to reference
I agree that Nabble is much more navigable. I've been linking to the
mail-archives.apache.org archive just because all the examples I've
seen of posting vote results seem to reference that site.
On Feb 13, 2007, at 7:48 AM, Bryan Noll wrote:
I just wanted to throw this up here real quick
First, I want to point out that I was wrong about needing to set a
lock level in code during an optimistic transaction. So actually for
us to run the benchmark, the only necessary setting is:
openjpa.LockManager: pessimistic
Contrary to what Patrick said and I backed up, we don't need to set
Secondly, are we parsing the XML file multiple times? The only
way for the first warning to be fired is if OpenJPA has read my
entity mappings, but the exception that is thrown later is a SAX
exception which implies that OpenJPA is reading the file again.
Sounds like an inefficient startup algo
On Feb 13, 2007, at 11:19 AM, Patrick Linskey wrote:
I also prefer ignoring it consistently. But considering that
enhancement fails, this seems like more than a WARN. More like a
SEVERE. And if you get a SEVERE during enhancement, should we
really put the EMF into service at all? Issue #2?
I a
Hi Kevin,
On Feb 13, 2007, at 11:25 AM, Kevin Sutter (JIRA) wrote:
Kevin Sutter commented on OPENJPA-141:
--
Personally, I think I provide sufficient due diligence on the
Issues that I own to stick with the normal "commit then review"
approach. There ar
[
https://issues.apache.org/jira/browse/OPENJPA-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472844
]
Dain Sundstrom commented on OPENJPA-142:
I think I found a related bug to this. When you have a mapped-supe
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472840
]
Kevin Sutter commented on OPENJPA-141:
--
Personally, I think I provide sufficient due diligence on the Issues th
> > I also prefer ignoring it consistently. But considering that
> > enhancement fails, this seems like more than a WARN. More like a
> > SEVERE. And if you get a SEVERE during enhancement, should we
> > really put the EMF into service at all? Issue #2?
>
> I agree. If we get an enhancement
On Feb 13, 2007, at 9:59 AM, Craig L Russell wrote:
Hi Dain,
Sounds like a jackpot full of issues here.
On Feb 13, 2007, at 9:17 AM, Dain Sundstrom wrote:
I found the problem. In my entity mappings file, I had a mapping
for a bean that no longer exists. When I comment out that
mapping,
On Feb 13, 2007, at 10:06 AM, Hans J. Prueller wrote:
Can you tell us your current J2EE vendor, and if possible the
generation
strategy selected in the vendor deployment descriptor. If not,
can you
grab the last 20 pks from one of the tables, we may be able to
guess the
strategy
One of
This benchmark runs best with a combination of optimistic locking
(most cases) and pessimistic locking (some specific uses identified
explicitly in the code).
Where concurrency is low, an optimistic approach works well. In
specific cases, optimistic results in bad performance due to the
n
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472829
]
Craig Russell commented on OPENJPA-141:
---
Given the number of iterations already documented on this issue, woul
> We'd also have to set the LockManager property to pessimistic to get
> database locks.
Hmm. It would seem that the LockManager should default to pessimistic
when Optimistic=false. Any reason why this is not the case?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
We'd also have to set the LockManager property to pessimistic to get
database locks. And just to build on what Patrick is saying: OpenJPA
can do locking within optimistic transactions on individual
instances, but you have to set a lock level on the FetchPlan in code,
which I don't think we
> Just to clarify... If we set up OpenJPA in this manner
> (Optimistic to false
> and the Read and Write Lock levels to None), then all
> transactions would
> then be running in Pessimistic mode, right? That is, we
> don't have the
> means of being more granular with these settings, do we?
I'
Exactly.
On 2/13/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472813]
Patrick Linskey commented on OPENJPA-141:
-
Patrick,
Just to clarify... If we set up OpenJPA in this manner (Optimistic to false
and the Read and Write Lock levels to None), then all transactions would
then be running in Pessimistic mode, right? That is, we don't have the
means of being more granular with these settings, do we?
Kevin
On
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472813
]
Patrick Linskey commented on OPENJPA-141:
-
> Please attach an svn patch to this JIRA when it's ready. I'd li
Hi Dain,
Sorry for not being clear. My comment was supposed to be about xml
bugs in general.
The annotations are very well tested in the TCK; the xml "overrides"
are reputedly less well tested, so it's likely that there are bugs to
be found in implementations, even if they pass the TCK. I
> Can you tell us your current J2EE vendor, and if possible the generation
> strategy selected in the vendor deployment descriptor. If not, can you
> grab the last 20 pks from one of the tables, we may be able to guess the
> strategy
One of the reasons why we are migrating is that the current
Patrick,
> It would certainly be possible to implement such a thing in OpenJPA, but
> there is no such feature in place currently.
perhaps this would be a nice feature for the future - if I'll find another
working solution that avoids the case of generating an already existing PK
I don't need it.
Hi Dain,
Sounds like a jackpot full of issues here.
On Feb 13, 2007, at 9:17 AM, Dain Sundstrom wrote:
I found the problem. In my entity mappings file, I had a mapping
for a bean that no longer exists. When I comment out that mapping,
the problem goes away. I only fond the problem by tur
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472795
]
Craig Russell commented on OPENJPA-141:
---
Nice work, Kevin and Abe.
Just a reminder. Please attach an svn patc
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472790
]
Kevin Sutter commented on OPENJPA-141:
--
Sounds good, Abe. Thanks for the comments, Abe and Craig. Here's the
[
https://issues.apache.org/jira/browse/OPENJPA-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472786
]
Patrick Linskey commented on OPENJPA-144:
-
Are you also specifying a jta-data-source, or only a non-jta-data
On Feb 13, 2007, at 11:30 AM, Dain Sundstrom wrote:
On Feb 13, 2007, at 5:27 AM, robert burrell donkin wrote:
On 2/13/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Pointing people at the page is good, but doesn't solve the problem.
i was a little confused about which problem you needed
Can you tell us your current J2EE vendor, and if possible the
generation strategy selected in the vendor deployment descriptor. If
not,
can you grab the last 20 pks from one of the tables, we may be able
to guess the strategy.
In general, if you vendor is using a UUID, you should able to u
JDBCConfigurationImpl does not support JNDI lookup for non-jta-data-source.
-
Key: OPENJPA-144
URL: https://issues.apache.org/jira/browse/OPENJPA-144
Project: OpenJPA
Problems with Single Table Inheritance Strategy (and Discriminator Type of
Integer)
---
Key: OPENJPA-143
URL: https://issues.apache.org/jira/browse/OPENJPA-143
Project: O
I found the problem. In my entity mappings file, I had a mapping for
a bean that no longer exists. When I comment out that mapping, the
problem goes away. I only fond the problem by turning the debug
level up (the full log is attached). In the log we do warn that the
class was not foun
> I can remember a legacy persistence framework that was able to retry
> the insert statement with a "second-try generated PK" just
> for the case
> the currently generated one has already been inserted by
> another process.
It would certainly be possible to implement such a thing in OpenJPA, bu
I doubt anyone has done much performance analysis of stock OpenJPA,
especially without caching. BEA's performance efforts obviously
focus on Kodo instead. Which is why we all appreciate the
performance work you're doing now, even if we (well, mostly just me)
might harp on the details.
__
thanks for this link but this section only describes the different
algorithms that are provided to get the generated value - it does
not mention the case what happens if we try to save a new persistent
entity with a generated PK value that already exists in the DB?
I can remember a legacy persiste
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472758
]
Abe White commented on OPENJPA-141:
---
Craig:
There doesn't appear to be any hashCode/equals performance issues. As
does openJPA provide the strategy to re-generate another value for
the PK
or do we have to manually deal with this case?
http://incubator.apache.org/openjpa/docs/latest/manual/
manual.html#ref_guide_sequence
___
Notice: Th
Excellent. I added a watch for this issue and will try out the fix
as soon it is available.
In the mean time, I changed my code generator to generate classes
with the exact entity name I want :)
-dain
On Feb 13, 2007, at 12:01 AM, Marc Prud'hommeaux wrote:
Dain-
I've reproduced this pr
On Feb 13, 2007, at 5:27 AM, robert burrell donkin wrote:
On 2/13/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Pointing people at the page is good, but doesn't solve the problem.
i was a little confused about which problem you needed to solve :-)
I think I want to make the list availab
Patrick,
thank you for your reply. The generation algorithm we are using currently
is provided from our EJB2.1 CMP container and is a blackbox for us.
As we are not very happy with the current solution we are
planning/evaluating the migration of the whole EJB2.1 persistence layer to
OpenJPA/JPA.
I just wanted to throw this up here real quick, because I noticed Marc
gave the apache archives site in one of his vote tally threads for
referencing
(http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/).
Someone has set this list up at Nabble.
http://www.nabble.com/open-jpa-dev
Hi,
There have been several requests about the performance analysis that we've
been doing. This performance analysis has resulted in three JIRA Issues
thus far (OPENJPA-115, OPENJPA-138, and OPENJPA-141) with more to come, I'm
sure. We're not ready to go public with the specific results yet, but
Just to add a "me too" to help out Dain... I have also seen this problem
while debugging other problems. At the time I figured I was doing something
wrong, so I didn't report it. I'll see if I can reproduce it again and
provide more insights.
Kevin
On 2/13/07, Marc Prud'hommeaux <[EMAIL PROTE
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472674
]
Kevin Sutter commented on OPENJPA-141:
--
> No, the current code holds the Classes with hard refs, and maps them
On 2/13/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Pointing people at the page is good, but doesn't solve the problem.
i was a little confused about which problem you needed to solve :-)
I think I want to make the list available to committers, but not
publicly. For example, what if a
Pointing people at the page is good, but doesn't solve the problem.
I think I want to make the list available to committers, but not
publicly. For example, what if a committer signs the NDA, and don't
tell their employer? committers participate here as individuals...
On Feb 13, 2007, at 8
On 2/12/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Yes, the problem is that it's not publicly visible. I need to solve
that...
http://www.apache.org/jcp names some lists
i could add some links to that page from the dev and incubator sites
(if that'd be any use)
- robert
With 7 votes in favor and none against, the vote passes!
The vote thread can be viewed at:
http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/
200702.mbox/[EMAIL PROTECTED]
I've updated the dependencies in the pom.xml file and committed.
Thanks to all who voted!
On Feb 9
[
https://issues.apache.org/jira/browse/OPENJPA-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472557
]
Marc Prud'hommeaux commented on OPENJPA-142:
This can be worked around by adding the annotation to the c
Dain-
I've reproduced this problem and reported it at:
https://issues.apache.org/jira/browse/OPENJPA-142
The only workaround is to add the @Entity(name="someAlias")
annotation to the class in addition to specifying it in the orm.xml
file.
On Feb 12, 2007, at 11:49 AM, Dain Sundstrom
52 matches
Mail list logo
