You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by om <mi...@ubs.com> on 2009/07/15 09:19:52 UTC
openJPA generates select per row - impossible to use for simple
select statements
Hi All!
I’m new in openJPA, and didn’t manage to get over the problem with simple
select statement for one object after a few days of investigation. Please
help!
For simple select from one object, OpenJPA ( same strategy for 1.0, 1.2.1,
2.0 ) fist generates right query to retrieve all rows and fields, and then
start generating query per object by primary key.
Code :
StringBuffer queryBuf = new StringBuffer("SELECT a FROM Account AS a
WHERE a.date = :date ");
PersistenceProviderImpl impl = new PersistenceProviderImpl();
OpenJPAEntityManagerFactory fac =
impl.createEntityManagerFactory("MainPersistence", System.getProperties());
OpenJPAEntityManager man = fac.createEntityManager();
Query query = man.createQuery(queryBuf.toString());
query.setParameter("date", reportDate);
List res = query.getResultList();
LOG TRACE
[7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE openjpa.Runtime -
Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached as target
query "null"
[7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE openjpa.Query -
Executing query: [SELECT a FROM Account AS a WHERE a.date = :date] with
parameters: {date=java.util.GregorianCalendar[]}
[7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE openjpa.jdbc.SQL
- <t 1495423266, conn 1329090360> executing prepstmnt 1388597956 SELECT
t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
[params=(Timestamp) 2009-07-03 00:00:00.0]
[7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE openjpa.jdbc.SQL -
<t 1495423266, conn 1329090360> [78 ms] spent
[7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE openjpa.jdbc.SQL -
<t 1495423266, conn 1329090360> executing prepstmnt 139855958 SELECT
t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE t0.id = ?
[params=(long) 328]
[7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE [WebContainer : 2]
openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
[7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE [WebContainer : 2]
openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0
WHERE t0.id = ? [params=(long) 329]
[7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE [WebContainer : 2]
openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
[7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE [WebContainer : 2]
openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0
WHERE t0.id = ? [params=(long) 330]
[7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE [WebContainer : 2]
openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
………………………………..
I need just list of detached objects to show it in grid. As it’s seen from
log trace above, first query is enough to return all necessary objects and
fields.
Why OpenJPA makes select per object after that? In this case simple code
above works 37 seconds for retrieving 440 rows, since same jdbc select and
wrap works 1.5 sec. I’ve tried different query hints and a few openjpa
versions, but with no result.
--
View this message in context: http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3261512.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
RE: openJPA generates select per row - impossible to use for simple select statements
Posted by "Ostryanin, Mikhail" <Mi...@ubs.com>.
Hi Kevin, Ravi,
Thank you very much for paying close attention to my problem. The issue
has been found and fixed due to your last messages. openJPA stopped
generating additional requests when I eliminated Util.resetTime(date) in
setDate() method. Since I couldn't imagine that it might somehow affect
generation process, I left this invocation while trying to simplify
Account object. So, when I substituted
this.date = Util.resetTime(date);
with
this.date = date;
in method
public void setDate(Calendar date)
it starts working fine.
Could anybody please let me know if it's an openJPA known restriction
(not to use other methods in getters and setters), or a bug?
Best regards,
Mikhail V. Ostryanin
Sr.Developer/Analyst
UBS, Moscow
Tel: +7 495 648 22 14
Mikhail.Ostryanin@UBS.com
-----Original Message-----
From: Kevin Sutter [mailto:kwsutter@gmail.com]
Sent: Thursday, July 16, 2009 9:08 PM
To: users@openjpa.apache.org
Subject: Re: openJPA generates select per row - impossible to use for
simple select statements
Doesn't seem to apply. I have also reproduced that error message with
my
testing, but I still haven't reproduced Mikhail's problem. Next option
is
to try Oracle...
On Thu, Jul 16, 2009 at 11:49 AM, Ravi Palacherla <
ravi.palacherla@oracle.com> wrote:
> Hi Kevin,
>
> I see the following in the log:
>
> [7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93
MainPersistence
> WARN [WebContainer : 0] openjpa.Enhance - [Possible violation of
> subclassing contract detected while processing persistent field
> com.ubs.n3.persistence.Account.date, declared in null. Are you sure
you are
> obeying the OpenJPA requirements? Details: The setter for field date
does
> not obey OpenJPAs subclassing restrictions. Setters must assign the
> passed-in parameter to a single field in the object.]
>
> Do you have any idea what it means ?
> Could it be related to this issue ?
>
> Regards,
> Ravi.
>
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Thursday, July 16, 2009 7:46 AM
> To: users@openjpa.apache.org
> Subject: Re: openJPA generates select per row - impossible to use for
> simple select statements
>
> :-) Totally agree that it doesn't make sense. I also noticed that
the
> cur_code field is not re-queried. Still investigating...
>
> On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
> Mikhail.Ostryanin@ubs.com> wrote:
>
> >
> > Hi!
> >
> > Thank you for response!
> >
> > You're right, this log file was produced by last openJPA 2.0
> > implementation linked to the application. But I have the same
problem
> > (generating additional select statements by primary key) with
OpenJPA
> > embedded in WebSphere, as well as WebSphere JPA itself ( as I know
it's
> > enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1 also.
> >
> > Anyway, problem still exists. What is most strange is that all
> > additional queries do not include field cur_code :
> >
> > executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name,
t0.acc_seq,
> > t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
> >
> > openJPA somehow decides that there's no need in querying cur_code,
but
> > it should query acc_name and some other fields. This logic does not
have
> > explicit comprehension, since both fields are declared and used same
way
> > in Account object.
> >
> > Best regards,
> > Mikhail V. Ostryanin
> > Sr.Developer/Analyst
> > UBS, Moscow
> > Tel: +7 495 648 22 14
> > Mikhail.Ostryanin@UBS.com
> >
> > -----Original Message-----
> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
> > Sent: Thursday, July 16, 2009 5:20 PM
> > To: users@openjpa.apache.org
> > Subject: Re: openJPA generates select per row - impossible to use
for
> > simple select statements
> >
> > Hi Mikhail,
> > Your log file is showing at least one difference from my
environment.
> > It
> > looks like you are (accidentally) using the subclassing support for
> > enhancement per this log statement:
> >
> > [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31
MainPersistence
> > INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for
> > "[class
> > com.ubs.n3.persistence.ReportBond, class
com.ubs.n3.persistence.Account,
> > class com.ubs.n3.persistence.N3Property]". This means that your
> > application
> > will be less efficient and will consume more memory than it would if
you
> > ran
> > the OpenJPA enhancer. Additionally, lazy loading will not be
available
> > for
> > one-to-one and many-to-one persistent attributes in types using
field
> > access; they will be loaded eagerly instead.
> >
> > I thought I had asked about what type of enhancement processing you
were
> > using, but maybe that was a different forum posting... You can find
out
> > more about OpenJPA's enhancement processing here [1]. In a
nutshell,
> > the
> > subclassing support is not meant for production use. It's meant for
> > some
> > simple, out of the box examples just to get people started. Real
usage
> > of
> > OpenJPA would use one of the enhancement processes.
> >
> > What's interesting is that you mention that you are using OpenJPA
within
> > WebSphere. The WebSphere packaged version of OpenJPA turns off this
> > subclassing support. If your applicaiton's processing should take
you
> > into
> > the subclassing support, an error message should be logged to let
you
> > know
> > of this condition. But, maybe you are just using OpenJPA as a
shared
> > library or an applicaiton library. In that case, the default,
> > last-ditch
> > attempt at enhancement is the subclassing support.
> >
> > I'm also not prepared to say that this is definitely your problem.
I'm
> > waiting for my development environment to boot up, so I will try it
out
> > shortly. But, anytime that I see subclassing with an error
condition,
> > it's
> > been a common culprit. I just wanted to get this bit of information
out
> > to
> > you so that maybe we can try out variations at the same time.
> >
> > Good luck,
> > Kevin
> >
> >
> >
> > [1]
> >
http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
> > l
> >
> > On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com>
wrote:
> >
> > >
> > > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
> > >
> > > Hi All,
> > >
> > > Thank you very much for paying attention to my problem. In spite
of it
> > > works
> > > with Hibernate, I don't like the idea to use another JPA and have
> > pretty
> > > many additional libs on board. I would like to fix the issue with
> > OpenJPA
> > > and use it since it's embedded in WebSphere server, at least.
> > >
> > > The code is extremely simple and clear. Stateless bean just
returns
> > > query.getResultList() to struts2 action , which puts it in request
> > object
> > > for displaytag grid. The whole time spends in
query.getResultList()
> > method.
> > >
> > > I've tried once more to remove IFilterTO and Map from Account
object,
> > but
> > > with no result.
> > >
> > > I put asterisks before and after query.getResultList(), switched
on
> > > runtime
> > > trace, and attached result log. It's pretty detailed, with many
> > openjpa
> > > runtime parameters and actions, may be somebody will be able to
> > determine
> > > what is happening...
> > >
> > > Database is ORACLE10, detailed version is present in attached log
file
> > -
> > > openJPA determined it correctly. Tables are created automatically
by
> > > OpenJPA
> > > using the following property in persistence.xml :
> > >
> > > <properties>
> > >
> > > <property name="openjpa.jdbc.SynchronizeMappings"
> > > value="buildSchema"/>
> > >
> > > </properties>
> > >
> > >
> > >
> > > IFilterTO interface just has two methods , nothing special :
> > >
> > > public interface IFilterTO {
> > > void setValue( String key, String value );
> > > String getValue( String key );
> > > }
> > >
> > > Thank you all in advance for your help.
> > >
> > > Mikhail
> > >
> > >
> > > Craig L Russell wrote:
> > > >
> > > > Hi,
> > > >
> > > > Could I ask again what the code is doing, following the
> > > > query.getResultList() ?
> > > >
> > > > Where is the list of results being used? Are the results being
> > > > serialized or detached?
> > > >
> > > > Thanks,
> > > >
> > > > Craig
> > > >
> > > > On Jul 15, 2009, at 12:19 AM, om wrote:
> > > >
> > > >>
> > > >> Hi All!
> > > >>
> > > >> I'm new in openJPA, and didn't manage to get over the problem
with
> > > >> simple
> > > >> select statement for one object after a few days of
investigation.
> > > >> Please
> > > >> help!
> > > >>
> > > >> For simple select from one object, OpenJPA ( same strategy for
1.0,
> > > >> 1.2.1,
> > > >> 2.0 ) fist generates right query to retrieve all rows and
fields,
> > > >> and then
> > > >> start generating query per object by primary key.
> > > >>
> > > >> Code :
> > > >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM
> > Account
> > > >> AS a
> > > >> WHERE a.date = :date ");
> > > >> PersistenceProviderImpl impl = new
PersistenceProviderImpl();
> > > >> OpenJPAEntityManagerFactory fac =
> > > >> impl.createEntityManagerFactory("MainPersistence",
> > > >> System.getProperties());
> > > >> OpenJPAEntityManager man = fac.createEntityManager();
> > > >>
> > > >> Query query = man.createQuery(queryBuf.toString());
> > > >> query.setParameter("date", reportDate);
> > > >> List res = query.getResultList();
> > > >>
> > > >>
> > > >> LOG TRACE
> > > >>
> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > > >> openjpa.Runtime -
> > > >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is
cached
> > > >> as target
> > > >> query "null"
> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > > >> openjpa.Query -
> > > >> Executing query: [SELECT a FROM Account AS a WHERE a.date =
:date]
> > > >> with
> > > >> parameters: {date=java.util.GregorianCalendar[]}
> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > > >> openjpa.jdbc.SQL
> > > >> - <t 1495423266, conn 1329090360> executing prepstmnt
1388597956
> > > >> SELECT
> > > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask,
t0.acc_name,
> > > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> > > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> > > >> openjpa.jdbc.SQL -
> > > >> <t 1495423266, conn 1329090360> [78 ms] spent
> > > >>
> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> > > >> openjpa.jdbc.SQL -
> > > >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958
> > SELECT
> > > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0
WHERE
> > > >> t0.id = ?
> > > >> [params=(long) 328]
> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> > > >> [WebContainer : 2]
> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
spent
> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> > > >> [WebContainer : 2]
> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> > prepstmnt
> > > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value
FROM
> > > >> ACCOUNT t0
> > > >> WHERE t0.id = ? [params=(long) 329]
> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> > > >> [WebContainer : 2]
> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
spent
> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> > > >> [WebContainer : 2]
> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> > prepstmnt
> > > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value
FROM
> > > >> ACCOUNT t0
> > > >> WHERE t0.id = ? [params=(long) 330]
> > > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
> > > >> [WebContainer : 2]
> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
spent
> > > >> ......................................
> > > >>
> > > >>
> > > >> I need just list of detached objects to show it in grid. As
it's
> > > >> seen from
> > > >> log trace above, first query is enough to return all necessary
> > > >> objects and
> > > >> fields.
> > > >> Why OpenJPA makes select per object after that? In this case
simple
> > > >> code
> > > >> above works 37 seconds for retrieving 440 rows, since same jdbc
> > > >> select and
> > > >> wrap works 1.5 sec. I've tried different query hints and a few
> > openjpa
> > > >> versions, but with no result.
> > > >>
> > > >>
> > > >> --
> > > >> View this message in context:
> > > >>
> > >
> >
http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> > e-for-simple-select-statements-tp3261512p3261512.html<
>
http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
%0Ae-for-simple-select-statements-tp3261512p3261512.html
> >
> > > >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> > > >
> > > > Craig L Russell
> > > > Architect, Sun Java Enterprise System http://db.apache.org/jdo
> > > > 408 276-5638 mailto:Craig.Russell@sun.com
> > > > P.S. A good JDO? O, Gasp!
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > View this message in context:
> > >
> >
http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> > e-for-simple-select-statements-tp3261512p3267829.html<
>
http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
%0Ae-for-simple-select-statements-tp3261512p3267829.html
> >
> > > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> > >
> > Visit our website at http://www.ubs.com
> >
> > This message contains confidential information and is intended only
> > for the individual named. If you are not the named addressee you
> > should not disseminate, distribute or copy this e-mail. Please
> > notify the sender immediately by e-mail if you have received this
> > e-mail by mistake and delete this e-mail from your system.
> >
> > E-mails are not encrypted and cannot be guaranteed to be secure or
> > error-free as information could be intercepted, corrupted, lost,
> > destroyed, arrive late or incomplete, or contain viruses. The
sender
> > therefore does not accept liability for any errors or omissions in
the
> > contents of this message which arise as a result of e-mail
transmission.
> > If verification is required please request a hard-copy version.
This
> > message is provided for informational purposes and should not be
> > construed as a solicitation or offer to buy or sell any securities
> > or related financial instruments.
> >
> >
> > UBS reserves the right to retain all messages. Messages are
protected
> > and accessed only in legally justified cases.
> >
>
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Michael Dick <mi...@gmail.com>.
On Wed, Jul 22, 2009 at 8:07 AM, Kevin Sutter <kw...@gmail.com> wrote:
> Hi Adam,
>
> On Wed, Jul 22, 2009 at 5:37 AM, Adam Hardy <adam.sql@cyberspaceroad.com
> >wrote:
>
> > Kevin Sutter on 21/07/09 14:42, wrote:
> >
> >>
> >> o In the Setter method for the proxied attribute, you must modify the
> >> value
> >> getting set. In this scenario, the Calendar object was being modified
> in
> >> the setDate method via the set() method.
> >>
> >
> > I thought putting code in your entities' setters and getters was
> considered
> > bad practice. Are you saying that there is much code in OpenJPA to cater
> for
> > this kind of thing?
>
>
> You are correct. Putting code in an entity's setters and getters is not a
> best practice. But, it's not forbidden either. OpenJPA actually logs a
> warning message when this situation is detected. But, we do not prevent
> it. Nor does the JPA spec forbid it.
>
I think Craig put it rather well here [1]. Putting code in accessor methods
is probably okay if you use field access. When you use property access it
gets easier to shoot yourself in the foot. Moving to field access might be
the easiest workaround for this particular problem.
This is probably something that should be explained better either in the
manual or on the wiki (maybe a FAQ page).
[1] http://markmail.org/message/gctzqmtjvxaejyxw
>
> This is actually one of the reasons why I didn't go forward with a patch
> just yet. Maybe the resolution will be to harden this warning message and
> not allow this type of modifications in the setters if you are using
> property-based access. But, to be honest, that seems a bit harsh. If
> OpenJPA can just be a tad bit smarter when loading entities from a query
> result set, then we could satisfy this request. Even if it's not a best
> practice.
>
+1, we can be smarter about this - even if it is a bit tricky to get into
this situation.
-mike
>
> Kevin
>
>
> >
> > Regards
> > Adam
> >
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Adam,
On Wed, Jul 22, 2009 at 5:37 AM, Adam Hardy <ad...@cyberspaceroad.com>wrote:
> Kevin Sutter on 21/07/09 14:42, wrote:
>
>>
>> o In the Setter method for the proxied attribute, you must modify the
>> value
>> getting set. In this scenario, the Calendar object was being modified in
>> the setDate method via the set() method.
>>
>
> I thought putting code in your entities' setters and getters was considered
> bad practice. Are you saying that there is much code in OpenJPA to cater for
> this kind of thing?
You are correct. Putting code in an entity's setters and getters is not a
best practice. But, it's not forbidden either. OpenJPA actually logs a
warning message when this situation is detected. But, we do not prevent
it. Nor does the JPA spec forbid it.
This is actually one of the reasons why I didn't go forward with a patch
just yet. Maybe the resolution will be to harden this warning message and
not allow this type of modifications in the setters if you are using
property-based access. But, to be honest, that seems a bit harsh. If
OpenJPA can just be a tad bit smarter when loading entities from a query
result set, then we could satisfy this request. Even if it's not a best
practice.
Kevin
>
> Regards
> Adam
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
JIRA Issue: https://issues.apache.org/jira/browse/OPENJPA-1188
On Tue, Jul 21, 2009 at 8:42 AM, Kevin Sutter <kw...@gmail.com> wrote:
> For those of you interested, here are the details on this problem and
> what's required to reproduce it. I will be opening a JIRA and posting a
> testcase shortly.
>
> Requirements...
>
> o Your Entity needs to have an attribute that OpenJPA wrappers with a
> proxy. This proxy is used to detect changes to these object types. Example
> object types that OpenJPA wrappers are Calendar (culprit for this scenario),
> Date, Collection, and Map.
>
> o In the Setter method for the proxied attribute, you must modify the
> value getting set. In this scenario, the Calendar object was being modified
> in the setDate method via the set() method.
>
> o The Entity must be using property-based access (annotations on the
> Getter methods).
>
> o The Persistence Context must be clear of any Entities that are being
> queried. For example, my testcase was persisting several Entities before
> executing the Query that was supposedly generating the extra SQL
> statements. If I didn't clear the Persistence Context before executing the
> Query, the Entities were already populated and it didn't trigger the extra
> SQL statements.
>
> o And, now comes the magic... :-) Access to the attribute's meta data
> seems to be done alphabetically. From what I can tell, this seems to be a
> Java format convention. In any case, the extra SQL statements are used to
> re-populate any attributes that are alphabetically after the proxied
> attribute that was modified in the corresponding Setter method.
>
> Given all of that setup, here's an explanation of what's happening...
>
> After the initial query is executed, the resulting Entity objects need to
> be populated with the data returned by the query. When the setter was
> called for this proxied attribute, and the value was modified, this
> attribute (and the Entity) was marked as being "dirty". Part of the dirty
> processing is to determine which fields need to be re-loaded. Of course,
> the proxied attribute does not have to be re-loaded since it was in the
> process of being modified. The id field does not have to re-loaded since
> we're using id generation for this particular scenario. And, any fields
> that are alphabetically before the proxied attribute were just loaded, so
> they don't have to be re-loaded. But, any fields that come after the
> proxied attribute (alphabetically) don't realize that they will be loaded
> (due to the original query), so the extra SQL is pushed out to load these
> fields.
>
> As you can see, many stars had to align to reproduce this scenario. I
> appreciate Mikhail's patience while we worked through the issue. And, I
> appreciate the extra insights from Mike and Ravi. This was actually quite
> fun to debug (in a sadistic point of view). :-)
>
> Thanks,
> Kevin
>
>
> On Mon, Jul 20, 2009 at 10:40 AM, Kevin Sutter <kw...@gmail.com> wrote:
>
>> I reproduced the problem! There's something about the logic in Mikhail's
>> resetTime method that is affecting the populating of the entities. My
>> resetTime() method had similar logic, but not exactly what Mikhail had. I
>> replaced the implementation and "poof" I reproduced the problem.
>>
>> I'll do some more experimenting to further isolate the problem and get a
>> JIRA filed (maybe even resolved).
>>
>> Thanks, Mikhail, for your patience and assistance. This was a strange
>> one, indeed.
>>
>> Kevin
>>
>>
>> On Mon, Jul 20, 2009 at 9:30 AM, om <mi...@ubs.com> wrote:
>>
>>>
>>> Hi,
>>> I don't have simple example. It looks like I can't help you here,
>>> unfortunately. This strange behavior occured on openJPA 1.0 embedded in
>>> WebSphere, OpenJPA 1.2.1 and last 2.0 versions linked to my application
>>> and
>>> initialized explicitly in code ( not through dependency injection ).
>>> Account
>>> object and persistence.xml are provided earlier, and they're extremely
>>> simple. Util.resetTime is extremely simple as well :
>>> public static Calendar resetTime(Calendar date) {
>>> if (date == null) return null;
>>> date.set(Calendar.HOUR_OF_DAY, 0);
>>> date.set(Calendar.MINUTE, 0);
>>> date.set(Calendar.SECOND, 0);
>>> date.set(Calendar.MILLISECOND, 0);
>>> return date;
>>> }
>>>
>>> WebSphere 6.1.0.21 with EJB3.0 pack, ORACLE version has been provided
>>> earlier (10.2.0.3 as I remember).
>>> Can't imagine what else can follow openJPA to this strange behavior...
>>>
>>>
>>> Kevin Sutter wrote:
>>> >
>>> > Hi Mikhail,
>>> > If you can believe this, I still can not reproduce the problem. What
>>> > exactly does your util.resetTime() method do?
>>> >
>>> > I have been trying your scenario with old and new versions of OpenJPA.
>>> I
>>> > even went back and used the same JVM (IBM JDK 5sr6b). Still no luck.
>>> >
>>> > I can't any references in the spec or the OpenJPA documentation that
>>> > restricts the code within getters and setters, but we do document how
>>> we
>>> > proxy Date classes (and other similar types) so that we can more easily
>>> > detect updates to these fields. You have shown how this affects your
>>> > usage. Now, we just need to get the development team to be able to
>>> > reproduce it so that we can figure out the root cause.
>>> >
>>> > Since it sounds like you have done much experimentation with this, do
>>> you
>>> > have a small example or project that demonstrates this problem?
>>> >
>>> > Thanks!
>>> > Kevin
>>> >
>>> > On Fri, Jul 17, 2009 at 7:50 AM, Kevin Sutter <kw...@gmail.com>
>>> wrote:
>>> >
>>> >> Mikhail,
>>> >> Great detective work. I thought I had verified that this didn't
>>> matter,
>>> >> but based on Mike's note below, I didn't actually replace the Date
>>> field
>>> >> with my helper method. That must have been the trick with reproducing
>>> >> the
>>> >> problem. I will try that out in my environment when I get to work and
>>> >> let
>>> >> you know.
>>> >>
>>> >> Thanks!
>>> >> Kevin
>>> >>
>>> >>
>>> >> On Fri, Jul 17, 2009 at 6:57 AM, Michael Dick
>>> >> <mi...@gmail.com>wrote:
>>> >>
>>> >>> I'm coming to this thread late (might not have all the info). OpenJPA
>>> >>> proxy's Date types and I'd guess this is a problem with replacing the
>>> >>> proxy.
>>> >>> Does the problem exist if you modify the existing data object instead
>>> of
>>> >>> creating a new one?
>>> >>>
>>> >>> -mike
>>> >>>
>>> >>> On Fri, Jul 17, 2009 at 2:03 AM, om <mi...@ubs.com>
>>> wrote:
>>> >>>
>>> >>> >
>>> >>> > Hi Kevin, Ravi,
>>> >>> >
>>> >>> > Thank you very much for paying close attention to my problem. The
>>> >>> issue
>>> >>> has
>>> >>> > been found and fixed due to your last messages. openJPA stopped
>>> >>> generating
>>> >>> > additional requests when I eliminated Util.resetTime(date) from
>>> >>> setDate()
>>> >>> > method. Since I couldn't imagine that it might somehow affect
>>> >>> generation
>>> >>> > process, I left this invocation while trying to simplify Account
>>> >>> object
>>> >>> > earlier. So, when I substituted
>>> >>> > this.date = Util.resetTime(date);
>>> >>> > with
>>> >>> > this.date = date;
>>> >>> >
>>> >>> > in method
>>> >>> > public void setDate(Calendar date)
>>> >>> >
>>> >>> > it started working fine.
>>> >>> >
>>> >>> > Could anybody please let me know if it's an openJPA known
>>> restriction
>>> >>> (not
>>> >>> > to use other methods in getters and setters), or a bug?
>>> >>> >
>>> >>> >
>>> >>> > Kevin Sutter wrote:
>>> >>> > >
>>> >>> > > Doesn't seem to apply. I have also reproduced that error message
>>> >>> with
>>> >>> my
>>> >>> > > testing, but I still haven't reproduced Mikhail's problem. Next
>>> >>> option
>>> >>> > is
>>> >>> > > to try Oracle...
>>> >>> > >
>>> >>> > > On Thu, Jul 16, 2009 at 11:49 AM, Ravi Palacherla <
>>> >>> > > ravi.palacherla@oracle.com> wrote:
>>> >>> > >
>>> >>> > >> Hi Kevin,
>>> >>> > >>
>>> >>> > >> I see the following in the log:
>>> >>> > >>
>>> >>> > >> [7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93
>>> >>> MainPersistence
>>> >>> > >> WARN [WebContainer : 0] openjpa.Enhance - [Possible violation
>>> of
>>> >>> > >> subclassing contract detected while processing persistent field
>>> >>> > >> com.ubs.n3.persistence.Account.date, declared in null. Are you
>>> sure
>>> >>> you
>>> >>> > >> are
>>> >>> > >> obeying the OpenJPA requirements? Details: The setter for field
>>> >>> date
>>> >>> > does
>>> >>> > >> not obey OpenJPAs subclassing restrictions. Setters must assign
>>> the
>>> >>> > >> passed-in parameter to a single field in the object.]
>>> >>> > >>
>>> >>> > >> Do you have any idea what it means ?
>>> >>> > >> Could it be related to this issue ?
>>> >>> > >>
>>> >>> > >> Regards,
>>> >>> > >> Ravi.
>>> >>> > >>
>>> >>> > >> -----Original Message-----
>>> >>> > >> From: Kevin Sutter [mailto:kwsutter@gmail.com]
>>> >>> > >> Sent: Thursday, July 16, 2009 7:46 AM
>>> >>> > >> To: users@openjpa.apache.org
>>> >>> > >> Subject: Re: openJPA generates select per row - impossible to
>>> use
>>> >>> for
>>> >>> > >> simple select statements
>>> >>> > >>
>>> >>> > >> :-) Totally agree that it doesn't make sense. I also noticed
>>> that
>>> >>> the
>>> >>> > >> cur_code field is not re-queried. Still investigating...
>>> >>> > >>
>>> >>> > >> On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
>>> >>> > >> Mikhail.Ostryanin@ubs.com> wrote:
>>> >>> > >>
>>> >>> > >> >
>>> >>> > >> > Hi!
>>> >>> > >> >
>>> >>> > >> > Thank you for response!
>>> >>> > >> >
>>> >>> > >> > You're right, this log file was produced by last openJPA 2.0
>>> >>> > >> > implementation linked to the application. But I have the same
>>> >>> problem
>>> >>> > >> > (generating additional select statements by primary key) with
>>> >>> OpenJPA
>>> >>> > >> > embedded in WebSphere, as well as WebSphere JPA itself ( as I
>>> >>> know
>>> >>> > it's
>>> >>> > >> > enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1
>>> >>> also.
>>> >>> > >> >
>>> >>> > >> > Anyway, problem still exists. What is most strange is that all
>>> >>> > >> > additional queries do not include field cur_code :
>>> >>> > >> >
>>> >>> > >> > executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name,
>>> >>> > t0.acc_seq,
>>> >>> > >> > t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
>>> >>> > >> >
>>> >>> > >> > openJPA somehow decides that there's no need in querying
>>> >>> cur_code,
>>> >>> but
>>> >>> > >> > it should query acc_name and some other fields. This logic
>>> does
>>> >>> not
>>> >>> > >> have
>>> >>> > >> > explicit comprehension, since both fields are declared and
>>> used
>>> >>> same
>>> >>> > >> way
>>> >>> > >> > in Account object.
>>> >>> > >> >
>>> >>> > >> > Best regards,
>>> >>> > >> > Mikhail V. Ostryanin
>>> >>> > >> > Sr.Developer/Analyst
>>> >>> > >> > UBS, Moscow
>>> >>> > >> > Tel: +7 495 648 22 14
>>> >>> > >> > Mikhail.Ostryanin@UBS.com
>>> >>> > >> >
>>> >>> > >> > -----Original Message-----
>>> >>> > >> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
>>> >>> > >> > Sent: Thursday, July 16, 2009 5:20 PM
>>> >>> > >> > To: users@openjpa.apache.org
>>> >>> > >> > Subject: Re: openJPA generates select per row - impossible to
>>> use
>>> >>> for
>>> >>> > >> > simple select statements
>>> >>> > >> >
>>> >>> > >> > Hi Mikhail,
>>> >>> > >> > Your log file is showing at least one difference from my
>>> >>> environment.
>>> >>> > >> > It
>>> >>> > >> > looks like you are (accidentally) using the subclassing
>>> support
>>> >>> for
>>> >>> > >> > enhancement per this log statement:
>>> >>> > >> >
>>> >>> > >> > [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31
>>> >>> > MainPersistence
>>> >>> > >> > INFO [WebContainer : 0] openjpa.Enhance - Creating subclass
>>> for
>>> >>> > >> > "[class
>>> >>> > >> > com.ubs.n3.persistence.ReportBond, class
>>> >>> > >> com.ubs.n3.persistence.Account,
>>> >>> > >> > class com.ubs.n3.persistence.N3Property]". This means that
>>> your
>>> >>> > >> > application
>>> >>> > >> > will be less efficient and will consume more memory than it
>>> would
>>> >>> if
>>> >>> > >> you
>>> >>> > >> > ran
>>> >>> > >> > the OpenJPA enhancer. Additionally, lazy loading will not be
>>> >>> available
>>> >>> > >> > for
>>> >>> > >> > one-to-one and many-to-one persistent attributes in types
>>> using
>>> >>> field
>>> >>> > >> > access; they will be loaded eagerly instead.
>>> >>> > >> >
>>> >>> > >> > I thought I had asked about what type of enhancement
>>> processing
>>> >>> you
>>> >>> > >> were
>>> >>> > >> > using, but maybe that was a different forum posting... You
>>> can
>>> >>> find
>>> >>> > >> out
>>> >>> > >> > more about OpenJPA's enhancement processing here [1]. In a
>>> >>> nutshell,
>>> >>> > >> > the
>>> >>> > >> > subclassing support is not meant for production use. It's
>>> meant
>>> >>> for
>>> >>> > >> > some
>>> >>> > >> > simple, out of the box examples just to get people started.
>>> Real
>>> >>> > usage
>>> >>> > >> > of
>>> >>> > >> > OpenJPA would use one of the enhancement processes.
>>> >>> > >> >
>>> >>> > >> > What's interesting is that you mention that you are using
>>> OpenJPA
>>> >>> > >> within
>>> >>> > >> > WebSphere. The WebSphere packaged version of OpenJPA turns
>>> off
>>> >>> this
>>> >>> > >> > subclassing support. If your applicaiton's processing should
>>> >>> take
>>> >>> you
>>> >>> > >> > into
>>> >>> > >> > the subclassing support, an error message should be logged to
>>> let
>>> >>> you
>>> >>> > >> > know
>>> >>> > >> > of this condition. But, maybe you are just using OpenJPA as a
>>> >>> shared
>>> >>> > >> > library or an applicaiton library. In that case, the default,
>>> >>> > >> > last-ditch
>>> >>> > >> > attempt at enhancement is the subclassing support.
>>> >>> > >> >
>>> >>> > >> > I'm also not prepared to say that this is definitely your
>>> >>> problem.
>>> >>> > I'm
>>> >>> > >> > waiting for my development environment to boot up, so I will
>>> try
>>> >>> it
>>> >>> > out
>>> >>> > >> > shortly. But, anytime that I see subclassing with an error
>>> >>> condition,
>>> >>> > >> > it's
>>> >>> > >> > been a common culprit. I just wanted to get this bit of
>>> >>> information
>>> >>> > >> out
>>> >>> > >> > to
>>> >>> > >> > you so that maybe we can try out variations at the same time.
>>> >>> > >> >
>>> >>> > >> > Good luck,
>>> >>> > >> > Kevin
>>> >>> > >> >
>>> >>> > >> >
>>> >>> > >> >
>>> >>> > >> > [1]
>>> >>> > >> >
>>> >>> > >>
>>> >>> >
>>> >>>
>>> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
>>> >>> > >> > l
>>> >>> > >> >
>>> >>> > >> > On Thu, Jul 16, 2009 at 4:41 AM, om <
>>> mikhail.ostryanin@ubs.com>
>>> >>> > wrote:
>>> >>> > >> >
>>> >>> > >> > >
>>> >>> > >> > > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
>>> >>> > >> > >
>>> >>> > >> > > Hi All,
>>> >>> > >> > >
>>> >>> > >> > > Thank you very much for paying attention to my problem. In
>>> >>> spite
>>> >>> of
>>> >>> > >> it
>>> >>> > >> > > works
>>> >>> > >> > > with Hibernate, I don't like the idea to use another JPA and
>>> >>> have
>>> >>> > >> > pretty
>>> >>> > >> > > many additional libs on board. I would like to fix the issue
>>> >>> with
>>> >>> > >> > OpenJPA
>>> >>> > >> > > and use it since it's embedded in WebSphere server, at
>>> least.
>>> >>> > >> > >
>>> >>> > >> > > The code is extremely simple and clear. Stateless bean just
>>> >>> returns
>>> >>> > >> > > query.getResultList() to struts2 action , which puts it in
>>> >>> request
>>> >>> > >> > object
>>> >>> > >> > > for displaytag grid. The whole time spends in
>>> >>> query.getResultList()
>>> >>> > >> > method.
>>> >>> > >> > >
>>> >>> > >> > > I've tried once more to remove IFilterTO and Map from
>>> Account
>>> >>> > object,
>>> >>> > >> > but
>>> >>> > >> > > with no result.
>>> >>> > >> > >
>>> >>> > >> > > I put asterisks before and after query.getResultList(),
>>> >>> switched
>>> >>> on
>>> >>> > >> > > runtime
>>> >>> > >> > > trace, and attached result log. It's pretty detailed, with
>>> many
>>> >>> > >> > openjpa
>>> >>> > >> > > runtime parameters and actions, may be somebody will be able
>>> to
>>> >>> > >> > determine
>>> >>> > >> > > what is happening...
>>> >>> > >> > >
>>> >>> > >> > > Database is ORACLE10, detailed version is present in
>>> attached
>>> >>> log
>>> >>> > >> file
>>> >>> > >> > -
>>> >>> > >> > > openJPA determined it correctly. Tables are created
>>> >>> automatically
>>> >>> by
>>> >>> > >> > > OpenJPA
>>> >>> > >> > > using the following property in persistence.xml :
>>> >>> > >> > >
>>> >>> > >> > > <properties>
>>> >>> > >> > >
>>> >>> > >> > > <property name="openjpa.jdbc.SynchronizeMappings"
>>> >>> > >> > > value="buildSchema"/>
>>> >>> > >> > >
>>> >>> > >> > > </properties>
>>> >>> > >> > >
>>> >>> > >> > >
>>> >>> > >> > >
>>> >>> > >> > > IFilterTO interface just has two methods , nothing special :
>>> >>> > >> > >
>>> >>> > >> > > public interface IFilterTO {
>>> >>> > >> > > void setValue( String key, String value );
>>> >>> > >> > > String getValue( String key );
>>> >>> > >> > > }
>>> >>> > >> > >
>>> >>> > >> > > Thank you all in advance for your help.
>>> >>> > >> > >
>>> >>> > >> > > Mikhail
>>> >>> > >> > >
>>> >>> > >> > >
>>> >>> > >> > > Craig L Russell wrote:
>>> >>> > >> > > >
>>> >>> > >> > > > Hi,
>>> >>> > >> > > >
>>> >>> > >> > > > Could I ask again what the code is doing, following the
>>> >>> > >> > > > query.getResultList() ?
>>> >>> > >> > > >
>>> >>> > >> > > > Where is the list of results being used? Are the results
>>> >>> being
>>> >>> > >> > > > serialized or detached?
>>> >>> > >> > > >
>>> >>> > >> > > > Thanks,
>>> >>> > >> > > >
>>> >>> > >> > > > Craig
>>> >>> > >> > > >
>>> >>> > >> > > > On Jul 15, 2009, at 12:19 AM, om wrote:
>>> >>> > >> > > >
>>> >>> > >> > > >>
>>> >>> > >> > > >> Hi All!
>>> >>> > >> > > >>
>>> >>> > >> > > >> I'm new in openJPA, and didn't manage to get over the
>>> >>> problem
>>> >>> > with
>>> >>> > >> > > >> simple
>>> >>> > >> > > >> select statement for one object after a few days of
>>> >>> > investigation.
>>> >>> > >> > > >> Please
>>> >>> > >> > > >> help!
>>> >>> > >> > > >>
>>> >>> > >> > > >> For simple select from one object, OpenJPA ( same
>>> strategy
>>> >>> for
>>> >>> > >> 1.0,
>>> >>> > >> > > >> 1.2.1,
>>> >>> > >> > > >> 2.0 ) fist generates right query to retrieve all rows and
>>> >>> fields,
>>> >>> > >> > > >> and then
>>> >>> > >> > > >> start generating query per object by primary key.
>>> >>> > >> > > >>
>>> >>> > >> > > >> Code :
>>> >>> > >> > > >> StringBuffer queryBuf = new StringBuffer("SELECT a
>>> FROM
>>> >>> > >> > Account
>>> >>> > >> > > >> AS a
>>> >>> > >> > > >> WHERE a.date = :date ");
>>> >>> > >> > > >> PersistenceProviderImpl impl = new
>>> >>> > PersistenceProviderImpl();
>>> >>> > >> > > >> OpenJPAEntityManagerFactory fac =
>>> >>> > >> > > >> impl.createEntityManagerFactory("MainPersistence",
>>> >>> > >> > > >> System.getProperties());
>>> >>> > >> > > >> OpenJPAEntityManager man =
>>> fac.createEntityManager();
>>> >>> > >> > > >>
>>> >>> > >> > > >> Query query = man.createQuery(queryBuf.toString());
>>> >>> > >> > > >> query.setParameter("date", reportDate);
>>> >>> > >> > > >> List res = query.getResultList();
>>> >>> > >> > > >>
>>> >>> > >> > > >>
>>> >>> > >> > > >> LOG TRACE
>>> >>> > >> > > >>
>>> >>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>>> >>> > >> > > >> openjpa.Runtime -
>>> >>> > >> > > >> Query "SELECT a FROM Account AS a WHERE a.date = :date "
>>> is
>>> >>> > cached
>>> >>> > >> > > >> as target
>>> >>> > >> > > >> query "null"
>>> >>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>>> >>> > >> > > >> openjpa.Query -
>>> >>> > >> > > >> Executing query: [SELECT a FROM Account AS a WHERE a.date
>>> =
>>> >>> > :date]
>>> >>> > >> > > >> with
>>> >>> > >> > > >> parameters: {date=java.util.GregorianCalendar[]}
>>> >>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>>> >>> > >> > > >> openjpa.jdbc.SQL
>>> >>> > >> > > >> - <t 1495423266, conn 1329090360> executing prepstmnt
>>> >>> 1388597956
>>> >>> > >> > > >> SELECT
>>> >>> > >> > > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask,
>>> >>> > t0.acc_name,
>>> >>> > >> > > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date =
>>> ?)
>>> >>> > >> > > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
>>> >>> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>>> >>> > >> > > >> openjpa.jdbc.SQL -
>>> >>> > >> > > >> <t 1495423266, conn 1329090360> [78 ms] spent
>>> >>> > >> > > >>
>>> >>> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>>> >>> > >> > > >> openjpa.jdbc.SQL -
>>> >>> > >> > > >> <t 1495423266, conn 1329090360> executing prepstmnt
>>> >>> 139855958
>>> >>> > >> > SELECT
>>> >>> > >> > > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT
>>> t0
>>> >>> WHERE
>>> >>> > >> > > >> t0.id = ?
>>> >>> > >> > > >> [params=(long) 328]
>>> >>> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>>> >>> > >> > > >> [WebContainer : 2]
>>> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78
>>> ms]
>>> >>> spent
>>> >>> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>>> >>> > >> > > >> [WebContainer : 2]
>>> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360>
>>> executing
>>> >>> > >> > prepstmnt
>>> >>> > >> > > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq,
>>> t0.value
>>> >>> FROM
>>> >>> > >> > > >> ACCOUNT t0
>>> >>> > >> > > >> WHERE t0.id = ? [params=(long) 329]
>>> >>> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>>> >>> > >> > > >> [WebContainer : 2]
>>> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78
>>> ms]
>>> >>> spent
>>> >>> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>>> >>> > >> > > >> [WebContainer : 2]
>>> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360>
>>> executing
>>> >>> > >> > prepstmnt
>>> >>> > >> > > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq,
>>> t0.value
>>> >>> FROM
>>> >>> > >> > > >> ACCOUNT t0
>>> >>> > >> > > >> WHERE t0.id = ? [params=(long) 330]
>>> >>> > >> > > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
>>> >>> > >> > > >> [WebContainer : 2]
>>> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78
>>> ms]
>>> >>> spent
>>> >>> > >> > > >> ......................................
>>> >>> > >> > > >>
>>> >>> > >> > > >>
>>> >>> > >> > > >> I need just list of detached objects to show it in grid.
>>> As
>>> >>> it's
>>> >>> > >> > > >> seen from
>>> >>> > >> > > >> log trace above, first query is enough to return all
>>> >>> necessary
>>> >>> > >> > > >> objects and
>>> >>> > >> > > >> fields.
>>> >>> > >> > > >> Why OpenJPA makes select per object after that? In this
>>> case
>>> >>> > >> simple
>>> >>> > >> > > >> code
>>> >>> > >> > > >> above works 37 seconds for retrieving 440 rows, since
>>> same
>>> >>> jdbc
>>> >>> > >> > > >> select and
>>> >>> > >> > > >> wrap works 1.5 sec. I've tried different query hints and
>>> a
>>> >>> few
>>> >>> > >> > openjpa
>>> >>> > >> > > >> versions, but with no result.
>>> >>> > >> > > >>
>>> >>> > >> > > >>
>>> >>> > >> > > >> --
>>> >>> > >> > > >> View this message in context:
>>> >>> > >> > > >>
>>> >>> > >> > >
>>> >>> > >> >
>>> >>> > >>
>>> >>> >
>>> >>>
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
>>> >>> > >> > e-for-simple-select-statements-tp3261512p3261512.html<
>>> >>> > >>
>>> >>> >
>>> >>>
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html
>>> >>> > >> >
>>> >>> > >> > > >> Sent from the OpenJPA Users mailing list archive at
>>> >>> Nabble.com.
>>> >>> > >> > > >
>>> >>> > >> > > > Craig L Russell
>>> >>> > >> > > > Architect, Sun Java Enterprise System
>>> >>> http://db.apache.org/jdo
>>> >>> > >> > > > 408 276-5638 mailto:Craig.Russell@sun.com
>>> >>> > >> > > > P.S. A good JDO? O, Gasp!
>>> >>> > >> > > >
>>> >>> > >> > > >
>>> >>> > >> > > >
>>> >>> > >> > > >
>>> >>> > >> > >
>>> >>> > >> > > --
>>> >>> > >> > > View this message in context:
>>> >>> > >> > >
>>> >>> > >> >
>>> >>> > >>
>>> >>> >
>>> >>>
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
>>> >>> > >> > e-for-simple-select-statements-tp3261512p3267829.html<
>>> >>> > >>
>>> >>> >
>>> >>>
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html
>>> >>> > >> >
>>> >>> > >> > > Sent from the OpenJPA Users mailing list archive at
>>> Nabble.com.
>>> >>> > >> > >
>>> >>> > >> > Visit our website at http://www.ubs.com
>>> >>> > >> >
>>> >>> > >> > This message contains confidential information and is intended
>>> >>> only
>>> >>> > >> > for the individual named. If you are not the named addressee
>>> you
>>> >>> > >> > should not disseminate, distribute or copy this e-mail.
>>> Please
>>> >>> > >> > notify the sender immediately by e-mail if you have received
>>> this
>>> >>> > >> > e-mail by mistake and delete this e-mail from your system.
>>> >>> > >> >
>>> >>> > >> > E-mails are not encrypted and cannot be guaranteed to be
>>> secure
>>> >>> or
>>> >>> > >> > error-free as information could be intercepted, corrupted,
>>> lost,
>>> >>> > >> > destroyed, arrive late or incomplete, or contain viruses. The
>>> >>> sender
>>> >>> > >> > therefore does not accept liability for any errors or
>>> omissions
>>> >>> in
>>> >>> the
>>> >>> > >> > contents of this message which arise as a result of e-mail
>>> >>> > >> transmission.
>>> >>> > >> > If verification is required please request a hard-copy
>>> version.
>>> >>> This
>>> >>> > >> > message is provided for informational purposes and should not
>>> be
>>> >>> > >> > construed as a solicitation or offer to buy or sell any
>>> >>> securities
>>> >>> > >> > or related financial instruments.
>>> >>> > >> >
>>> >>> > >> >
>>> >>> > >> > UBS reserves the right to retain all messages. Messages are
>>> >>> protected
>>> >>> > >> > and accessed only in legally justified cases.
>>> >>> > >> >
>>> >>> > >>
>>> >>> > >
>>> >>> > >
>>> >>> >
>>> >>> > --
>>> >>> > View this message in context:
>>> >>> >
>>> >>>
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3273854.html
>>> >>> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>> >>> >
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3289150.html
>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>>
>>
>>
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Adam Hardy <ad...@cyberspaceroad.com>.
Kevin Sutter on 21/07/09 14:42, wrote:
> For those of you interested, here are the details on this problem and what's
> required to reproduce it. I will be opening a JIRA and posting a testcase
> shortly.
>
> Requirements...
>
> o Your Entity needs to have an attribute that OpenJPA wrappers with a
> proxy. This proxy is used to detect changes to these object types. Example
> object types that OpenJPA wrappers are Calendar (culprit for this scenario),
> Date, Collection, and Map.
>
> o In the Setter method for the proxied attribute, you must modify the value
> getting set. In this scenario, the Calendar object was being modified in
> the setDate method via the set() method.
I thought putting code in your entities' setters and getters was considered bad
practice. Are you saying that there is much code in OpenJPA to cater for this
kind of thing?
Regards
Adam
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
For those of you interested, here are the details on this problem and what's
required to reproduce it. I will be opening a JIRA and posting a testcase
shortly.
Requirements...
o Your Entity needs to have an attribute that OpenJPA wrappers with a
proxy. This proxy is used to detect changes to these object types. Example
object types that OpenJPA wrappers are Calendar (culprit for this scenario),
Date, Collection, and Map.
o In the Setter method for the proxied attribute, you must modify the value
getting set. In this scenario, the Calendar object was being modified in
the setDate method via the set() method.
o The Entity must be using property-based access (annotations on the Getter
methods).
o The Persistence Context must be clear of any Entities that are being
queried. For example, my testcase was persisting several Entities before
executing the Query that was supposedly generating the extra SQL
statements. If I didn't clear the Persistence Context before executing the
Query, the Entities were already populated and it didn't trigger the extra
SQL statements.
o And, now comes the magic... :-) Access to the attribute's meta data
seems to be done alphabetically. From what I can tell, this seems to be a
Java format convention. In any case, the extra SQL statements are used to
re-populate any attributes that are alphabetically after the proxied
attribute that was modified in the corresponding Setter method.
Given all of that setup, here's an explanation of what's happening...
After the initial query is executed, the resulting Entity objects need to be
populated with the data returned by the query. When the setter was called
for this proxied attribute, and the value was modified, this attribute (and
the Entity) was marked as being "dirty". Part of the dirty processing is to
determine which fields need to be re-loaded. Of course, the proxied
attribute does not have to be re-loaded since it was in the process of being
modified. The id field does not have to re-loaded since we're using id
generation for this particular scenario. And, any fields that are
alphabetically before the proxied attribute were just loaded, so they don't
have to be re-loaded. But, any fields that come after the proxied attribute
(alphabetically) don't realize that they will be loaded (due to the original
query), so the extra SQL is pushed out to load these fields.
As you can see, many stars had to align to reproduce this scenario. I
appreciate Mikhail's patience while we worked through the issue. And, I
appreciate the extra insights from Mike and Ravi. This was actually quite
fun to debug (in a sadistic point of view). :-)
Thanks,
Kevin
On Mon, Jul 20, 2009 at 10:40 AM, Kevin Sutter <kw...@gmail.com> wrote:
> I reproduced the problem! There's something about the logic in Mikhail's
> resetTime method that is affecting the populating of the entities. My
> resetTime() method had similar logic, but not exactly what Mikhail had. I
> replaced the implementation and "poof" I reproduced the problem.
>
> I'll do some more experimenting to further isolate the problem and get a
> JIRA filed (maybe even resolved).
>
> Thanks, Mikhail, for your patience and assistance. This was a strange one,
> indeed.
>
> Kevin
>
>
> On Mon, Jul 20, 2009 at 9:30 AM, om <mi...@ubs.com> wrote:
>
>>
>> Hi,
>> I don't have simple example. It looks like I can't help you here,
>> unfortunately. This strange behavior occured on openJPA 1.0 embedded in
>> WebSphere, OpenJPA 1.2.1 and last 2.0 versions linked to my application
>> and
>> initialized explicitly in code ( not through dependency injection ).
>> Account
>> object and persistence.xml are provided earlier, and they're extremely
>> simple. Util.resetTime is extremely simple as well :
>> public static Calendar resetTime(Calendar date) {
>> if (date == null) return null;
>> date.set(Calendar.HOUR_OF_DAY, 0);
>> date.set(Calendar.MINUTE, 0);
>> date.set(Calendar.SECOND, 0);
>> date.set(Calendar.MILLISECOND, 0);
>> return date;
>> }
>>
>> WebSphere 6.1.0.21 with EJB3.0 pack, ORACLE version has been provided
>> earlier (10.2.0.3 as I remember).
>> Can't imagine what else can follow openJPA to this strange behavior...
>>
>>
>> Kevin Sutter wrote:
>> >
>> > Hi Mikhail,
>> > If you can believe this, I still can not reproduce the problem. What
>> > exactly does your util.resetTime() method do?
>> >
>> > I have been trying your scenario with old and new versions of OpenJPA.
>> I
>> > even went back and used the same JVM (IBM JDK 5sr6b). Still no luck.
>> >
>> > I can't any references in the spec or the OpenJPA documentation that
>> > restricts the code within getters and setters, but we do document how we
>> > proxy Date classes (and other similar types) so that we can more easily
>> > detect updates to these fields. You have shown how this affects your
>> > usage. Now, we just need to get the development team to be able to
>> > reproduce it so that we can figure out the root cause.
>> >
>> > Since it sounds like you have done much experimentation with this, do
>> you
>> > have a small example or project that demonstrates this problem?
>> >
>> > Thanks!
>> > Kevin
>> >
>> > On Fri, Jul 17, 2009 at 7:50 AM, Kevin Sutter <kw...@gmail.com>
>> wrote:
>> >
>> >> Mikhail,
>> >> Great detective work. I thought I had verified that this didn't
>> matter,
>> >> but based on Mike's note below, I didn't actually replace the Date
>> field
>> >> with my helper method. That must have been the trick with reproducing
>> >> the
>> >> problem. I will try that out in my environment when I get to work and
>> >> let
>> >> you know.
>> >>
>> >> Thanks!
>> >> Kevin
>> >>
>> >>
>> >> On Fri, Jul 17, 2009 at 6:57 AM, Michael Dick
>> >> <mi...@gmail.com>wrote:
>> >>
>> >>> I'm coming to this thread late (might not have all the info). OpenJPA
>> >>> proxy's Date types and I'd guess this is a problem with replacing the
>> >>> proxy.
>> >>> Does the problem exist if you modify the existing data object instead
>> of
>> >>> creating a new one?
>> >>>
>> >>> -mike
>> >>>
>> >>> On Fri, Jul 17, 2009 at 2:03 AM, om <mi...@ubs.com>
>> wrote:
>> >>>
>> >>> >
>> >>> > Hi Kevin, Ravi,
>> >>> >
>> >>> > Thank you very much for paying close attention to my problem. The
>> >>> issue
>> >>> has
>> >>> > been found and fixed due to your last messages. openJPA stopped
>> >>> generating
>> >>> > additional requests when I eliminated Util.resetTime(date) from
>> >>> setDate()
>> >>> > method. Since I couldn't imagine that it might somehow affect
>> >>> generation
>> >>> > process, I left this invocation while trying to simplify Account
>> >>> object
>> >>> > earlier. So, when I substituted
>> >>> > this.date = Util.resetTime(date);
>> >>> > with
>> >>> > this.date = date;
>> >>> >
>> >>> > in method
>> >>> > public void setDate(Calendar date)
>> >>> >
>> >>> > it started working fine.
>> >>> >
>> >>> > Could anybody please let me know if it's an openJPA known
>> restriction
>> >>> (not
>> >>> > to use other methods in getters and setters), or a bug?
>> >>> >
>> >>> >
>> >>> > Kevin Sutter wrote:
>> >>> > >
>> >>> > > Doesn't seem to apply. I have also reproduced that error message
>> >>> with
>> >>> my
>> >>> > > testing, but I still haven't reproduced Mikhail's problem. Next
>> >>> option
>> >>> > is
>> >>> > > to try Oracle...
>> >>> > >
>> >>> > > On Thu, Jul 16, 2009 at 11:49 AM, Ravi Palacherla <
>> >>> > > ravi.palacherla@oracle.com> wrote:
>> >>> > >
>> >>> > >> Hi Kevin,
>> >>> > >>
>> >>> > >> I see the following in the log:
>> >>> > >>
>> >>> > >> [7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93
>> >>> MainPersistence
>> >>> > >> WARN [WebContainer : 0] openjpa.Enhance - [Possible violation
>> of
>> >>> > >> subclassing contract detected while processing persistent field
>> >>> > >> com.ubs.n3.persistence.Account.date, declared in null. Are you
>> sure
>> >>> you
>> >>> > >> are
>> >>> > >> obeying the OpenJPA requirements? Details: The setter for field
>> >>> date
>> >>> > does
>> >>> > >> not obey OpenJPAs subclassing restrictions. Setters must assign
>> the
>> >>> > >> passed-in parameter to a single field in the object.]
>> >>> > >>
>> >>> > >> Do you have any idea what it means ?
>> >>> > >> Could it be related to this issue ?
>> >>> > >>
>> >>> > >> Regards,
>> >>> > >> Ravi.
>> >>> > >>
>> >>> > >> -----Original Message-----
>> >>> > >> From: Kevin Sutter [mailto:kwsutter@gmail.com]
>> >>> > >> Sent: Thursday, July 16, 2009 7:46 AM
>> >>> > >> To: users@openjpa.apache.org
>> >>> > >> Subject: Re: openJPA generates select per row - impossible to use
>> >>> for
>> >>> > >> simple select statements
>> >>> > >>
>> >>> > >> :-) Totally agree that it doesn't make sense. I also noticed
>> that
>> >>> the
>> >>> > >> cur_code field is not re-queried. Still investigating...
>> >>> > >>
>> >>> > >> On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
>> >>> > >> Mikhail.Ostryanin@ubs.com> wrote:
>> >>> > >>
>> >>> > >> >
>> >>> > >> > Hi!
>> >>> > >> >
>> >>> > >> > Thank you for response!
>> >>> > >> >
>> >>> > >> > You're right, this log file was produced by last openJPA 2.0
>> >>> > >> > implementation linked to the application. But I have the same
>> >>> problem
>> >>> > >> > (generating additional select statements by primary key) with
>> >>> OpenJPA
>> >>> > >> > embedded in WebSphere, as well as WebSphere JPA itself ( as I
>> >>> know
>> >>> > it's
>> >>> > >> > enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1
>> >>> also.
>> >>> > >> >
>> >>> > >> > Anyway, problem still exists. What is most strange is that all
>> >>> > >> > additional queries do not include field cur_code :
>> >>> > >> >
>> >>> > >> > executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name,
>> >>> > t0.acc_seq,
>> >>> > >> > t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
>> >>> > >> >
>> >>> > >> > openJPA somehow decides that there's no need in querying
>> >>> cur_code,
>> >>> but
>> >>> > >> > it should query acc_name and some other fields. This logic does
>> >>> not
>> >>> > >> have
>> >>> > >> > explicit comprehension, since both fields are declared and used
>> >>> same
>> >>> > >> way
>> >>> > >> > in Account object.
>> >>> > >> >
>> >>> > >> > Best regards,
>> >>> > >> > Mikhail V. Ostryanin
>> >>> > >> > Sr.Developer/Analyst
>> >>> > >> > UBS, Moscow
>> >>> > >> > Tel: +7 495 648 22 14
>> >>> > >> > Mikhail.Ostryanin@UBS.com
>> >>> > >> >
>> >>> > >> > -----Original Message-----
>> >>> > >> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
>> >>> > >> > Sent: Thursday, July 16, 2009 5:20 PM
>> >>> > >> > To: users@openjpa.apache.org
>> >>> > >> > Subject: Re: openJPA generates select per row - impossible to
>> use
>> >>> for
>> >>> > >> > simple select statements
>> >>> > >> >
>> >>> > >> > Hi Mikhail,
>> >>> > >> > Your log file is showing at least one difference from my
>> >>> environment.
>> >>> > >> > It
>> >>> > >> > looks like you are (accidentally) using the subclassing support
>> >>> for
>> >>> > >> > enhancement per this log statement:
>> >>> > >> >
>> >>> > >> > [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31
>> >>> > MainPersistence
>> >>> > >> > INFO [WebContainer : 0] openjpa.Enhance - Creating subclass
>> for
>> >>> > >> > "[class
>> >>> > >> > com.ubs.n3.persistence.ReportBond, class
>> >>> > >> com.ubs.n3.persistence.Account,
>> >>> > >> > class com.ubs.n3.persistence.N3Property]". This means that your
>> >>> > >> > application
>> >>> > >> > will be less efficient and will consume more memory than it
>> would
>> >>> if
>> >>> > >> you
>> >>> > >> > ran
>> >>> > >> > the OpenJPA enhancer. Additionally, lazy loading will not be
>> >>> available
>> >>> > >> > for
>> >>> > >> > one-to-one and many-to-one persistent attributes in types using
>> >>> field
>> >>> > >> > access; they will be loaded eagerly instead.
>> >>> > >> >
>> >>> > >> > I thought I had asked about what type of enhancement processing
>> >>> you
>> >>> > >> were
>> >>> > >> > using, but maybe that was a different forum posting... You can
>> >>> find
>> >>> > >> out
>> >>> > >> > more about OpenJPA's enhancement processing here [1]. In a
>> >>> nutshell,
>> >>> > >> > the
>> >>> > >> > subclassing support is not meant for production use. It's
>> meant
>> >>> for
>> >>> > >> > some
>> >>> > >> > simple, out of the box examples just to get people started.
>> Real
>> >>> > usage
>> >>> > >> > of
>> >>> > >> > OpenJPA would use one of the enhancement processes.
>> >>> > >> >
>> >>> > >> > What's interesting is that you mention that you are using
>> OpenJPA
>> >>> > >> within
>> >>> > >> > WebSphere. The WebSphere packaged version of OpenJPA turns off
>> >>> this
>> >>> > >> > subclassing support. If your applicaiton's processing should
>> >>> take
>> >>> you
>> >>> > >> > into
>> >>> > >> > the subclassing support, an error message should be logged to
>> let
>> >>> you
>> >>> > >> > know
>> >>> > >> > of this condition. But, maybe you are just using OpenJPA as a
>> >>> shared
>> >>> > >> > library or an applicaiton library. In that case, the default,
>> >>> > >> > last-ditch
>> >>> > >> > attempt at enhancement is the subclassing support.
>> >>> > >> >
>> >>> > >> > I'm also not prepared to say that this is definitely your
>> >>> problem.
>> >>> > I'm
>> >>> > >> > waiting for my development environment to boot up, so I will
>> try
>> >>> it
>> >>> > out
>> >>> > >> > shortly. But, anytime that I see subclassing with an error
>> >>> condition,
>> >>> > >> > it's
>> >>> > >> > been a common culprit. I just wanted to get this bit of
>> >>> information
>> >>> > >> out
>> >>> > >> > to
>> >>> > >> > you so that maybe we can try out variations at the same time.
>> >>> > >> >
>> >>> > >> > Good luck,
>> >>> > >> > Kevin
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> > [1]
>> >>> > >> >
>> >>> > >>
>> >>> >
>> >>>
>> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
>> >>> > >> > l
>> >>> > >> >
>> >>> > >> > On Thu, Jul 16, 2009 at 4:41 AM, om <mikhail.ostryanin@ubs.com
>> >
>> >>> > wrote:
>> >>> > >> >
>> >>> > >> > >
>> >>> > >> > > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
>> >>> > >> > >
>> >>> > >> > > Hi All,
>> >>> > >> > >
>> >>> > >> > > Thank you very much for paying attention to my problem. In
>> >>> spite
>> >>> of
>> >>> > >> it
>> >>> > >> > > works
>> >>> > >> > > with Hibernate, I don't like the idea to use another JPA and
>> >>> have
>> >>> > >> > pretty
>> >>> > >> > > many additional libs on board. I would like to fix the issue
>> >>> with
>> >>> > >> > OpenJPA
>> >>> > >> > > and use it since it's embedded in WebSphere server, at least.
>> >>> > >> > >
>> >>> > >> > > The code is extremely simple and clear. Stateless bean just
>> >>> returns
>> >>> > >> > > query.getResultList() to struts2 action , which puts it in
>> >>> request
>> >>> > >> > object
>> >>> > >> > > for displaytag grid. The whole time spends in
>> >>> query.getResultList()
>> >>> > >> > method.
>> >>> > >> > >
>> >>> > >> > > I've tried once more to remove IFilterTO and Map from Account
>> >>> > object,
>> >>> > >> > but
>> >>> > >> > > with no result.
>> >>> > >> > >
>> >>> > >> > > I put asterisks before and after query.getResultList(),
>> >>> switched
>> >>> on
>> >>> > >> > > runtime
>> >>> > >> > > trace, and attached result log. It's pretty detailed, with
>> many
>> >>> > >> > openjpa
>> >>> > >> > > runtime parameters and actions, may be somebody will be able
>> to
>> >>> > >> > determine
>> >>> > >> > > what is happening...
>> >>> > >> > >
>> >>> > >> > > Database is ORACLE10, detailed version is present in attached
>> >>> log
>> >>> > >> file
>> >>> > >> > -
>> >>> > >> > > openJPA determined it correctly. Tables are created
>> >>> automatically
>> >>> by
>> >>> > >> > > OpenJPA
>> >>> > >> > > using the following property in persistence.xml :
>> >>> > >> > >
>> >>> > >> > > <properties>
>> >>> > >> > >
>> >>> > >> > > <property name="openjpa.jdbc.SynchronizeMappings"
>> >>> > >> > > value="buildSchema"/>
>> >>> > >> > >
>> >>> > >> > > </properties>
>> >>> > >> > >
>> >>> > >> > >
>> >>> > >> > >
>> >>> > >> > > IFilterTO interface just has two methods , nothing special :
>> >>> > >> > >
>> >>> > >> > > public interface IFilterTO {
>> >>> > >> > > void setValue( String key, String value );
>> >>> > >> > > String getValue( String key );
>> >>> > >> > > }
>> >>> > >> > >
>> >>> > >> > > Thank you all in advance for your help.
>> >>> > >> > >
>> >>> > >> > > Mikhail
>> >>> > >> > >
>> >>> > >> > >
>> >>> > >> > > Craig L Russell wrote:
>> >>> > >> > > >
>> >>> > >> > > > Hi,
>> >>> > >> > > >
>> >>> > >> > > > Could I ask again what the code is doing, following the
>> >>> > >> > > > query.getResultList() ?
>> >>> > >> > > >
>> >>> > >> > > > Where is the list of results being used? Are the results
>> >>> being
>> >>> > >> > > > serialized or detached?
>> >>> > >> > > >
>> >>> > >> > > > Thanks,
>> >>> > >> > > >
>> >>> > >> > > > Craig
>> >>> > >> > > >
>> >>> > >> > > > On Jul 15, 2009, at 12:19 AM, om wrote:
>> >>> > >> > > >
>> >>> > >> > > >>
>> >>> > >> > > >> Hi All!
>> >>> > >> > > >>
>> >>> > >> > > >> I'm new in openJPA, and didn't manage to get over the
>> >>> problem
>> >>> > with
>> >>> > >> > > >> simple
>> >>> > >> > > >> select statement for one object after a few days of
>> >>> > investigation.
>> >>> > >> > > >> Please
>> >>> > >> > > >> help!
>> >>> > >> > > >>
>> >>> > >> > > >> For simple select from one object, OpenJPA ( same strategy
>> >>> for
>> >>> > >> 1.0,
>> >>> > >> > > >> 1.2.1,
>> >>> > >> > > >> 2.0 ) fist generates right query to retrieve all rows and
>> >>> fields,
>> >>> > >> > > >> and then
>> >>> > >> > > >> start generating query per object by primary key.
>> >>> > >> > > >>
>> >>> > >> > > >> Code :
>> >>> > >> > > >> StringBuffer queryBuf = new StringBuffer("SELECT a
>> FROM
>> >>> > >> > Account
>> >>> > >> > > >> AS a
>> >>> > >> > > >> WHERE a.date = :date ");
>> >>> > >> > > >> PersistenceProviderImpl impl = new
>> >>> > PersistenceProviderImpl();
>> >>> > >> > > >> OpenJPAEntityManagerFactory fac =
>> >>> > >> > > >> impl.createEntityManagerFactory("MainPersistence",
>> >>> > >> > > >> System.getProperties());
>> >>> > >> > > >> OpenJPAEntityManager man = fac.createEntityManager();
>> >>> > >> > > >>
>> >>> > >> > > >> Query query = man.createQuery(queryBuf.toString());
>> >>> > >> > > >> query.setParameter("date", reportDate);
>> >>> > >> > > >> List res = query.getResultList();
>> >>> > >> > > >>
>> >>> > >> > > >>
>> >>> > >> > > >> LOG TRACE
>> >>> > >> > > >>
>> >>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> >>> > >> > > >> openjpa.Runtime -
>> >>> > >> > > >> Query "SELECT a FROM Account AS a WHERE a.date = :date "
>> is
>> >>> > cached
>> >>> > >> > > >> as target
>> >>> > >> > > >> query "null"
>> >>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> >>> > >> > > >> openjpa.Query -
>> >>> > >> > > >> Executing query: [SELECT a FROM Account AS a WHERE a.date
>> =
>> >>> > :date]
>> >>> > >> > > >> with
>> >>> > >> > > >> parameters: {date=java.util.GregorianCalendar[]}
>> >>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> >>> > >> > > >> openjpa.jdbc.SQL
>> >>> > >> > > >> - <t 1495423266, conn 1329090360> executing prepstmnt
>> >>> 1388597956
>> >>> > >> > > >> SELECT
>> >>> > >> > > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask,
>> >>> > t0.acc_name,
>> >>> > >> > > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date =
>> ?)
>> >>> > >> > > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
>> >>> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> >>> > >> > > >> openjpa.jdbc.SQL -
>> >>> > >> > > >> <t 1495423266, conn 1329090360> [78 ms] spent
>> >>> > >> > > >>
>> >>> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> >>> > >> > > >> openjpa.jdbc.SQL -
>> >>> > >> > > >> <t 1495423266, conn 1329090360> executing prepstmnt
>> >>> 139855958
>> >>> > >> > SELECT
>> >>> > >> > > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0
>> >>> WHERE
>> >>> > >> > > >> t0.id = ?
>> >>> > >> > > >> [params=(long) 328]
>> >>> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>> >>> > >> > > >> [WebContainer : 2]
>> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
>> >>> spent
>> >>> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>> >>> > >> > > >> [WebContainer : 2]
>> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360>
>> executing
>> >>> > >> > prepstmnt
>> >>> > >> > > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq,
>> t0.value
>> >>> FROM
>> >>> > >> > > >> ACCOUNT t0
>> >>> > >> > > >> WHERE t0.id = ? [params=(long) 329]
>> >>> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>> >>> > >> > > >> [WebContainer : 2]
>> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
>> >>> spent
>> >>> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>> >>> > >> > > >> [WebContainer : 2]
>> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360>
>> executing
>> >>> > >> > prepstmnt
>> >>> > >> > > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq,
>> t0.value
>> >>> FROM
>> >>> > >> > > >> ACCOUNT t0
>> >>> > >> > > >> WHERE t0.id = ? [params=(long) 330]
>> >>> > >> > > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
>> >>> > >> > > >> [WebContainer : 2]
>> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
>> >>> spent
>> >>> > >> > > >> ......................................
>> >>> > >> > > >>
>> >>> > >> > > >>
>> >>> > >> > > >> I need just list of detached objects to show it in grid.
>> As
>> >>> it's
>> >>> > >> > > >> seen from
>> >>> > >> > > >> log trace above, first query is enough to return all
>> >>> necessary
>> >>> > >> > > >> objects and
>> >>> > >> > > >> fields.
>> >>> > >> > > >> Why OpenJPA makes select per object after that? In this
>> case
>> >>> > >> simple
>> >>> > >> > > >> code
>> >>> > >> > > >> above works 37 seconds for retrieving 440 rows, since same
>> >>> jdbc
>> >>> > >> > > >> select and
>> >>> > >> > > >> wrap works 1.5 sec. I've tried different query hints and a
>> >>> few
>> >>> > >> > openjpa
>> >>> > >> > > >> versions, but with no result.
>> >>> > >> > > >>
>> >>> > >> > > >>
>> >>> > >> > > >> --
>> >>> > >> > > >> View this message in context:
>> >>> > >> > > >>
>> >>> > >> > >
>> >>> > >> >
>> >>> > >>
>> >>> >
>> >>>
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
>> >>> > >> > e-for-simple-select-statements-tp3261512p3261512.html<
>> >>> > >>
>> >>> >
>> >>>
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html
>> >>> > >> >
>> >>> > >> > > >> Sent from the OpenJPA Users mailing list archive at
>> >>> Nabble.com.
>> >>> > >> > > >
>> >>> > >> > > > Craig L Russell
>> >>> > >> > > > Architect, Sun Java Enterprise System
>> >>> http://db.apache.org/jdo
>> >>> > >> > > > 408 276-5638 mailto:Craig.Russell@sun.com
>> >>> > >> > > > P.S. A good JDO? O, Gasp!
>> >>> > >> > > >
>> >>> > >> > > >
>> >>> > >> > > >
>> >>> > >> > > >
>> >>> > >> > >
>> >>> > >> > > --
>> >>> > >> > > View this message in context:
>> >>> > >> > >
>> >>> > >> >
>> >>> > >>
>> >>> >
>> >>>
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
>> >>> > >> > e-for-simple-select-statements-tp3261512p3267829.html<
>> >>> > >>
>> >>> >
>> >>>
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html
>> >>> > >> >
>> >>> > >> > > Sent from the OpenJPA Users mailing list archive at
>> Nabble.com.
>> >>> > >> > >
>> >>> > >> > Visit our website at http://www.ubs.com
>> >>> > >> >
>> >>> > >> > This message contains confidential information and is intended
>> >>> only
>> >>> > >> > for the individual named. If you are not the named addressee
>> you
>> >>> > >> > should not disseminate, distribute or copy this e-mail. Please
>> >>> > >> > notify the sender immediately by e-mail if you have received
>> this
>> >>> > >> > e-mail by mistake and delete this e-mail from your system.
>> >>> > >> >
>> >>> > >> > E-mails are not encrypted and cannot be guaranteed to be secure
>> >>> or
>> >>> > >> > error-free as information could be intercepted, corrupted,
>> lost,
>> >>> > >> > destroyed, arrive late or incomplete, or contain viruses. The
>> >>> sender
>> >>> > >> > therefore does not accept liability for any errors or omissions
>> >>> in
>> >>> the
>> >>> > >> > contents of this message which arise as a result of e-mail
>> >>> > >> transmission.
>> >>> > >> > If verification is required please request a hard-copy version.
>> >>> This
>> >>> > >> > message is provided for informational purposes and should not
>> be
>> >>> > >> > construed as a solicitation or offer to buy or sell any
>> >>> securities
>> >>> > >> > or related financial instruments.
>> >>> > >> >
>> >>> > >> >
>> >>> > >> > UBS reserves the right to retain all messages. Messages are
>> >>> protected
>> >>> > >> > and accessed only in legally justified cases.
>> >>> > >> >
>> >>> > >>
>> >>> > >
>> >>> > >
>> >>> >
>> >>> > --
>> >>> > View this message in context:
>> >>> >
>> >>>
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3273854.html
>> >>> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
>> >>> >
>> >>>
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3289150.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
I reproduced the problem! There's something about the logic in Mikhail's
resetTime method that is affecting the populating of the entities. My
resetTime() method had similar logic, but not exactly what Mikhail had. I
replaced the implementation and "poof" I reproduced the problem.
I'll do some more experimenting to further isolate the problem and get a
JIRA filed (maybe even resolved).
Thanks, Mikhail, for your patience and assistance. This was a strange one,
indeed.
Kevin
On Mon, Jul 20, 2009 at 9:30 AM, om <mi...@ubs.com> wrote:
>
> Hi,
> I don't have simple example. It looks like I can't help you here,
> unfortunately. This strange behavior occured on openJPA 1.0 embedded in
> WebSphere, OpenJPA 1.2.1 and last 2.0 versions linked to my application and
> initialized explicitly in code ( not through dependency injection ).
> Account
> object and persistence.xml are provided earlier, and they're extremely
> simple. Util.resetTime is extremely simple as well :
> public static Calendar resetTime(Calendar date) {
> if (date == null) return null;
> date.set(Calendar.HOUR_OF_DAY, 0);
> date.set(Calendar.MINUTE, 0);
> date.set(Calendar.SECOND, 0);
> date.set(Calendar.MILLISECOND, 0);
> return date;
> }
>
> WebSphere 6.1.0.21 with EJB3.0 pack, ORACLE version has been provided
> earlier (10.2.0.3 as I remember).
> Can't imagine what else can follow openJPA to this strange behavior...
>
>
> Kevin Sutter wrote:
> >
> > Hi Mikhail,
> > If you can believe this, I still can not reproduce the problem. What
> > exactly does your util.resetTime() method do?
> >
> > I have been trying your scenario with old and new versions of OpenJPA. I
> > even went back and used the same JVM (IBM JDK 5sr6b). Still no luck.
> >
> > I can't any references in the spec or the OpenJPA documentation that
> > restricts the code within getters and setters, but we do document how we
> > proxy Date classes (and other similar types) so that we can more easily
> > detect updates to these fields. You have shown how this affects your
> > usage. Now, we just need to get the development team to be able to
> > reproduce it so that we can figure out the root cause.
> >
> > Since it sounds like you have done much experimentation with this, do you
> > have a small example or project that demonstrates this problem?
> >
> > Thanks!
> > Kevin
> >
> > On Fri, Jul 17, 2009 at 7:50 AM, Kevin Sutter <kw...@gmail.com>
> wrote:
> >
> >> Mikhail,
> >> Great detective work. I thought I had verified that this didn't matter,
> >> but based on Mike's note below, I didn't actually replace the Date field
> >> with my helper method. That must have been the trick with reproducing
> >> the
> >> problem. I will try that out in my environment when I get to work and
> >> let
> >> you know.
> >>
> >> Thanks!
> >> Kevin
> >>
> >>
> >> On Fri, Jul 17, 2009 at 6:57 AM, Michael Dick
> >> <mi...@gmail.com>wrote:
> >>
> >>> I'm coming to this thread late (might not have all the info). OpenJPA
> >>> proxy's Date types and I'd guess this is a problem with replacing the
> >>> proxy.
> >>> Does the problem exist if you modify the existing data object instead
> of
> >>> creating a new one?
> >>>
> >>> -mike
> >>>
> >>> On Fri, Jul 17, 2009 at 2:03 AM, om <mi...@ubs.com> wrote:
> >>>
> >>> >
> >>> > Hi Kevin, Ravi,
> >>> >
> >>> > Thank you very much for paying close attention to my problem. The
> >>> issue
> >>> has
> >>> > been found and fixed due to your last messages. openJPA stopped
> >>> generating
> >>> > additional requests when I eliminated Util.resetTime(date) from
> >>> setDate()
> >>> > method. Since I couldn't imagine that it might somehow affect
> >>> generation
> >>> > process, I left this invocation while trying to simplify Account
> >>> object
> >>> > earlier. So, when I substituted
> >>> > this.date = Util.resetTime(date);
> >>> > with
> >>> > this.date = date;
> >>> >
> >>> > in method
> >>> > public void setDate(Calendar date)
> >>> >
> >>> > it started working fine.
> >>> >
> >>> > Could anybody please let me know if it's an openJPA known restriction
> >>> (not
> >>> > to use other methods in getters and setters), or a bug?
> >>> >
> >>> >
> >>> > Kevin Sutter wrote:
> >>> > >
> >>> > > Doesn't seem to apply. I have also reproduced that error message
> >>> with
> >>> my
> >>> > > testing, but I still haven't reproduced Mikhail's problem. Next
> >>> option
> >>> > is
> >>> > > to try Oracle...
> >>> > >
> >>> > > On Thu, Jul 16, 2009 at 11:49 AM, Ravi Palacherla <
> >>> > > ravi.palacherla@oracle.com> wrote:
> >>> > >
> >>> > >> Hi Kevin,
> >>> > >>
> >>> > >> I see the following in the log:
> >>> > >>
> >>> > >> [7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93
> >>> MainPersistence
> >>> > >> WARN [WebContainer : 0] openjpa.Enhance - [Possible violation
> of
> >>> > >> subclassing contract detected while processing persistent field
> >>> > >> com.ubs.n3.persistence.Account.date, declared in null. Are you
> sure
> >>> you
> >>> > >> are
> >>> > >> obeying the OpenJPA requirements? Details: The setter for field
> >>> date
> >>> > does
> >>> > >> not obey OpenJPAs subclassing restrictions. Setters must assign
> the
> >>> > >> passed-in parameter to a single field in the object.]
> >>> > >>
> >>> > >> Do you have any idea what it means ?
> >>> > >> Could it be related to this issue ?
> >>> > >>
> >>> > >> Regards,
> >>> > >> Ravi.
> >>> > >>
> >>> > >> -----Original Message-----
> >>> > >> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> >>> > >> Sent: Thursday, July 16, 2009 7:46 AM
> >>> > >> To: users@openjpa.apache.org
> >>> > >> Subject: Re: openJPA generates select per row - impossible to use
> >>> for
> >>> > >> simple select statements
> >>> > >>
> >>> > >> :-) Totally agree that it doesn't make sense. I also noticed
> that
> >>> the
> >>> > >> cur_code field is not re-queried. Still investigating...
> >>> > >>
> >>> > >> On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
> >>> > >> Mikhail.Ostryanin@ubs.com> wrote:
> >>> > >>
> >>> > >> >
> >>> > >> > Hi!
> >>> > >> >
> >>> > >> > Thank you for response!
> >>> > >> >
> >>> > >> > You're right, this log file was produced by last openJPA 2.0
> >>> > >> > implementation linked to the application. But I have the same
> >>> problem
> >>> > >> > (generating additional select statements by primary key) with
> >>> OpenJPA
> >>> > >> > embedded in WebSphere, as well as WebSphere JPA itself ( as I
> >>> know
> >>> > it's
> >>> > >> > enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1
> >>> also.
> >>> > >> >
> >>> > >> > Anyway, problem still exists. What is most strange is that all
> >>> > >> > additional queries do not include field cur_code :
> >>> > >> >
> >>> > >> > executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name,
> >>> > t0.acc_seq,
> >>> > >> > t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
> >>> > >> >
> >>> > >> > openJPA somehow decides that there's no need in querying
> >>> cur_code,
> >>> but
> >>> > >> > it should query acc_name and some other fields. This logic does
> >>> not
> >>> > >> have
> >>> > >> > explicit comprehension, since both fields are declared and used
> >>> same
> >>> > >> way
> >>> > >> > in Account object.
> >>> > >> >
> >>> > >> > Best regards,
> >>> > >> > Mikhail V. Ostryanin
> >>> > >> > Sr.Developer/Analyst
> >>> > >> > UBS, Moscow
> >>> > >> > Tel: +7 495 648 22 14
> >>> > >> > Mikhail.Ostryanin@UBS.com
> >>> > >> >
> >>> > >> > -----Original Message-----
> >>> > >> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
> >>> > >> > Sent: Thursday, July 16, 2009 5:20 PM
> >>> > >> > To: users@openjpa.apache.org
> >>> > >> > Subject: Re: openJPA generates select per row - impossible to
> use
> >>> for
> >>> > >> > simple select statements
> >>> > >> >
> >>> > >> > Hi Mikhail,
> >>> > >> > Your log file is showing at least one difference from my
> >>> environment.
> >>> > >> > It
> >>> > >> > looks like you are (accidentally) using the subclassing support
> >>> for
> >>> > >> > enhancement per this log statement:
> >>> > >> >
> >>> > >> > [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31
> >>> > MainPersistence
> >>> > >> > INFO [WebContainer : 0] openjpa.Enhance - Creating subclass
> for
> >>> > >> > "[class
> >>> > >> > com.ubs.n3.persistence.ReportBond, class
> >>> > >> com.ubs.n3.persistence.Account,
> >>> > >> > class com.ubs.n3.persistence.N3Property]". This means that your
> >>> > >> > application
> >>> > >> > will be less efficient and will consume more memory than it
> would
> >>> if
> >>> > >> you
> >>> > >> > ran
> >>> > >> > the OpenJPA enhancer. Additionally, lazy loading will not be
> >>> available
> >>> > >> > for
> >>> > >> > one-to-one and many-to-one persistent attributes in types using
> >>> field
> >>> > >> > access; they will be loaded eagerly instead.
> >>> > >> >
> >>> > >> > I thought I had asked about what type of enhancement processing
> >>> you
> >>> > >> were
> >>> > >> > using, but maybe that was a different forum posting... You can
> >>> find
> >>> > >> out
> >>> > >> > more about OpenJPA's enhancement processing here [1]. In a
> >>> nutshell,
> >>> > >> > the
> >>> > >> > subclassing support is not meant for production use. It's meant
> >>> for
> >>> > >> > some
> >>> > >> > simple, out of the box examples just to get people started.
> Real
> >>> > usage
> >>> > >> > of
> >>> > >> > OpenJPA would use one of the enhancement processes.
> >>> > >> >
> >>> > >> > What's interesting is that you mention that you are using
> OpenJPA
> >>> > >> within
> >>> > >> > WebSphere. The WebSphere packaged version of OpenJPA turns off
> >>> this
> >>> > >> > subclassing support. If your applicaiton's processing should
> >>> take
> >>> you
> >>> > >> > into
> >>> > >> > the subclassing support, an error message should be logged to
> let
> >>> you
> >>> > >> > know
> >>> > >> > of this condition. But, maybe you are just using OpenJPA as a
> >>> shared
> >>> > >> > library or an applicaiton library. In that case, the default,
> >>> > >> > last-ditch
> >>> > >> > attempt at enhancement is the subclassing support.
> >>> > >> >
> >>> > >> > I'm also not prepared to say that this is definitely your
> >>> problem.
> >>> > I'm
> >>> > >> > waiting for my development environment to boot up, so I will try
> >>> it
> >>> > out
> >>> > >> > shortly. But, anytime that I see subclassing with an error
> >>> condition,
> >>> > >> > it's
> >>> > >> > been a common culprit. I just wanted to get this bit of
> >>> information
> >>> > >> out
> >>> > >> > to
> >>> > >> > you so that maybe we can try out variations at the same time.
> >>> > >> >
> >>> > >> > Good luck,
> >>> > >> > Kevin
> >>> > >> >
> >>> > >> >
> >>> > >> >
> >>> > >> > [1]
> >>> > >> >
> >>> > >>
> >>> >
> >>>
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
> >>> > >> > l
> >>> > >> >
> >>> > >> > On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com>
> >>> > wrote:
> >>> > >> >
> >>> > >> > >
> >>> > >> > > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
> >>> > >> > >
> >>> > >> > > Hi All,
> >>> > >> > >
> >>> > >> > > Thank you very much for paying attention to my problem. In
> >>> spite
> >>> of
> >>> > >> it
> >>> > >> > > works
> >>> > >> > > with Hibernate, I don't like the idea to use another JPA and
> >>> have
> >>> > >> > pretty
> >>> > >> > > many additional libs on board. I would like to fix the issue
> >>> with
> >>> > >> > OpenJPA
> >>> > >> > > and use it since it's embedded in WebSphere server, at least.
> >>> > >> > >
> >>> > >> > > The code is extremely simple and clear. Stateless bean just
> >>> returns
> >>> > >> > > query.getResultList() to struts2 action , which puts it in
> >>> request
> >>> > >> > object
> >>> > >> > > for displaytag grid. The whole time spends in
> >>> query.getResultList()
> >>> > >> > method.
> >>> > >> > >
> >>> > >> > > I've tried once more to remove IFilterTO and Map from Account
> >>> > object,
> >>> > >> > but
> >>> > >> > > with no result.
> >>> > >> > >
> >>> > >> > > I put asterisks before and after query.getResultList(),
> >>> switched
> >>> on
> >>> > >> > > runtime
> >>> > >> > > trace, and attached result log. It's pretty detailed, with
> many
> >>> > >> > openjpa
> >>> > >> > > runtime parameters and actions, may be somebody will be able
> to
> >>> > >> > determine
> >>> > >> > > what is happening...
> >>> > >> > >
> >>> > >> > > Database is ORACLE10, detailed version is present in attached
> >>> log
> >>> > >> file
> >>> > >> > -
> >>> > >> > > openJPA determined it correctly. Tables are created
> >>> automatically
> >>> by
> >>> > >> > > OpenJPA
> >>> > >> > > using the following property in persistence.xml :
> >>> > >> > >
> >>> > >> > > <properties>
> >>> > >> > >
> >>> > >> > > <property name="openjpa.jdbc.SynchronizeMappings"
> >>> > >> > > value="buildSchema"/>
> >>> > >> > >
> >>> > >> > > </properties>
> >>> > >> > >
> >>> > >> > >
> >>> > >> > >
> >>> > >> > > IFilterTO interface just has two methods , nothing special :
> >>> > >> > >
> >>> > >> > > public interface IFilterTO {
> >>> > >> > > void setValue( String key, String value );
> >>> > >> > > String getValue( String key );
> >>> > >> > > }
> >>> > >> > >
> >>> > >> > > Thank you all in advance for your help.
> >>> > >> > >
> >>> > >> > > Mikhail
> >>> > >> > >
> >>> > >> > >
> >>> > >> > > Craig L Russell wrote:
> >>> > >> > > >
> >>> > >> > > > Hi,
> >>> > >> > > >
> >>> > >> > > > Could I ask again what the code is doing, following the
> >>> > >> > > > query.getResultList() ?
> >>> > >> > > >
> >>> > >> > > > Where is the list of results being used? Are the results
> >>> being
> >>> > >> > > > serialized or detached?
> >>> > >> > > >
> >>> > >> > > > Thanks,
> >>> > >> > > >
> >>> > >> > > > Craig
> >>> > >> > > >
> >>> > >> > > > On Jul 15, 2009, at 12:19 AM, om wrote:
> >>> > >> > > >
> >>> > >> > > >>
> >>> > >> > > >> Hi All!
> >>> > >> > > >>
> >>> > >> > > >> I'm new in openJPA, and didn't manage to get over the
> >>> problem
> >>> > with
> >>> > >> > > >> simple
> >>> > >> > > >> select statement for one object after a few days of
> >>> > investigation.
> >>> > >> > > >> Please
> >>> > >> > > >> help!
> >>> > >> > > >>
> >>> > >> > > >> For simple select from one object, OpenJPA ( same strategy
> >>> for
> >>> > >> 1.0,
> >>> > >> > > >> 1.2.1,
> >>> > >> > > >> 2.0 ) fist generates right query to retrieve all rows and
> >>> fields,
> >>> > >> > > >> and then
> >>> > >> > > >> start generating query per object by primary key.
> >>> > >> > > >>
> >>> > >> > > >> Code :
> >>> > >> > > >> StringBuffer queryBuf = new StringBuffer("SELECT a
> FROM
> >>> > >> > Account
> >>> > >> > > >> AS a
> >>> > >> > > >> WHERE a.date = :date ");
> >>> > >> > > >> PersistenceProviderImpl impl = new
> >>> > PersistenceProviderImpl();
> >>> > >> > > >> OpenJPAEntityManagerFactory fac =
> >>> > >> > > >> impl.createEntityManagerFactory("MainPersistence",
> >>> > >> > > >> System.getProperties());
> >>> > >> > > >> OpenJPAEntityManager man = fac.createEntityManager();
> >>> > >> > > >>
> >>> > >> > > >> Query query = man.createQuery(queryBuf.toString());
> >>> > >> > > >> query.setParameter("date", reportDate);
> >>> > >> > > >> List res = query.getResultList();
> >>> > >> > > >>
> >>> > >> > > >>
> >>> > >> > > >> LOG TRACE
> >>> > >> > > >>
> >>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >>> > >> > > >> openjpa.Runtime -
> >>> > >> > > >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is
> >>> > cached
> >>> > >> > > >> as target
> >>> > >> > > >> query "null"
> >>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >>> > >> > > >> openjpa.Query -
> >>> > >> > > >> Executing query: [SELECT a FROM Account AS a WHERE a.date =
> >>> > :date]
> >>> > >> > > >> with
> >>> > >> > > >> parameters: {date=java.util.GregorianCalendar[]}
> >>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >>> > >> > > >> openjpa.jdbc.SQL
> >>> > >> > > >> - <t 1495423266, conn 1329090360> executing prepstmnt
> >>> 1388597956
> >>> > >> > > >> SELECT
> >>> > >> > > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask,
> >>> > t0.acc_name,
> >>> > >> > > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date =
> ?)
> >>> > >> > > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
> >>> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> >>> > >> > > >> openjpa.jdbc.SQL -
> >>> > >> > > >> <t 1495423266, conn 1329090360> [78 ms] spent
> >>> > >> > > >>
> >>> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> >>> > >> > > >> openjpa.jdbc.SQL -
> >>> > >> > > >> <t 1495423266, conn 1329090360> executing prepstmnt
> >>> 139855958
> >>> > >> > SELECT
> >>> > >> > > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0
> >>> WHERE
> >>> > >> > > >> t0.id = ?
> >>> > >> > > >> [params=(long) 328]
> >>> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> >>> > >> > > >> [WebContainer : 2]
> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
> >>> spent
> >>> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> >>> > >> > > >> [WebContainer : 2]
> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360>
> executing
> >>> > >> > prepstmnt
> >>> > >> > > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value
> >>> FROM
> >>> > >> > > >> ACCOUNT t0
> >>> > >> > > >> WHERE t0.id = ? [params=(long) 329]
> >>> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> >>> > >> > > >> [WebContainer : 2]
> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
> >>> spent
> >>> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> >>> > >> > > >> [WebContainer : 2]
> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360>
> executing
> >>> > >> > prepstmnt
> >>> > >> > > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq,
> t0.value
> >>> FROM
> >>> > >> > > >> ACCOUNT t0
> >>> > >> > > >> WHERE t0.id = ? [params=(long) 330]
> >>> > >> > > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
> >>> > >> > > >> [WebContainer : 2]
> >>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
> >>> spent
> >>> > >> > > >> ......................................
> >>> > >> > > >>
> >>> > >> > > >>
> >>> > >> > > >> I need just list of detached objects to show it in grid. As
> >>> it's
> >>> > >> > > >> seen from
> >>> > >> > > >> log trace above, first query is enough to return all
> >>> necessary
> >>> > >> > > >> objects and
> >>> > >> > > >> fields.
> >>> > >> > > >> Why OpenJPA makes select per object after that? In this
> case
> >>> > >> simple
> >>> > >> > > >> code
> >>> > >> > > >> above works 37 seconds for retrieving 440 rows, since same
> >>> jdbc
> >>> > >> > > >> select and
> >>> > >> > > >> wrap works 1.5 sec. I've tried different query hints and a
> >>> few
> >>> > >> > openjpa
> >>> > >> > > >> versions, but with no result.
> >>> > >> > > >>
> >>> > >> > > >>
> >>> > >> > > >> --
> >>> > >> > > >> View this message in context:
> >>> > >> > > >>
> >>> > >> > >
> >>> > >> >
> >>> > >>
> >>> >
> >>>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> >>> > >> > e-for-simple-select-statements-tp3261512p3261512.html<
> >>> > >>
> >>> >
> >>>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html
> >>> > >> >
> >>> > >> > > >> Sent from the OpenJPA Users mailing list archive at
> >>> Nabble.com.
> >>> > >> > > >
> >>> > >> > > > Craig L Russell
> >>> > >> > > > Architect, Sun Java Enterprise System
> >>> http://db.apache.org/jdo
> >>> > >> > > > 408 276-5638 mailto:Craig.Russell@sun.com
> >>> > >> > > > P.S. A good JDO? O, Gasp!
> >>> > >> > > >
> >>> > >> > > >
> >>> > >> > > >
> >>> > >> > > >
> >>> > >> > >
> >>> > >> > > --
> >>> > >> > > View this message in context:
> >>> > >> > >
> >>> > >> >
> >>> > >>
> >>> >
> >>>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> >>> > >> > e-for-simple-select-statements-tp3261512p3267829.html<
> >>> > >>
> >>> >
> >>>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html
> >>> > >> >
> >>> > >> > > Sent from the OpenJPA Users mailing list archive at
> Nabble.com.
> >>> > >> > >
> >>> > >> > Visit our website at http://www.ubs.com
> >>> > >> >
> >>> > >> > This message contains confidential information and is intended
> >>> only
> >>> > >> > for the individual named. If you are not the named addressee
> you
> >>> > >> > should not disseminate, distribute or copy this e-mail. Please
> >>> > >> > notify the sender immediately by e-mail if you have received
> this
> >>> > >> > e-mail by mistake and delete this e-mail from your system.
> >>> > >> >
> >>> > >> > E-mails are not encrypted and cannot be guaranteed to be secure
> >>> or
> >>> > >> > error-free as information could be intercepted, corrupted, lost,
> >>> > >> > destroyed, arrive late or incomplete, or contain viruses. The
> >>> sender
> >>> > >> > therefore does not accept liability for any errors or omissions
> >>> in
> >>> the
> >>> > >> > contents of this message which arise as a result of e-mail
> >>> > >> transmission.
> >>> > >> > If verification is required please request a hard-copy version.
> >>> This
> >>> > >> > message is provided for informational purposes and should not be
> >>> > >> > construed as a solicitation or offer to buy or sell any
> >>> securities
> >>> > >> > or related financial instruments.
> >>> > >> >
> >>> > >> >
> >>> > >> > UBS reserves the right to retain all messages. Messages are
> >>> protected
> >>> > >> > and accessed only in legally justified cases.
> >>> > >> >
> >>> > >>
> >>> > >
> >>> > >
> >>> >
> >>> > --
> >>> > View this message in context:
> >>> >
> >>>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3273854.html
> >>> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>> >
> >>>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3289150.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by om <mi...@ubs.com>.
Hi,
I don't have simple example. It looks like I can't help you here,
unfortunately. This strange behavior occured on openJPA 1.0 embedded in
WebSphere, OpenJPA 1.2.1 and last 2.0 versions linked to my application and
initialized explicitly in code ( not through dependency injection ). Account
object and persistence.xml are provided earlier, and they're extremely
simple. Util.resetTime is extremely simple as well :
public static Calendar resetTime(Calendar date) {
if (date == null) return null;
date.set(Calendar.HOUR_OF_DAY, 0);
date.set(Calendar.MINUTE, 0);
date.set(Calendar.SECOND, 0);
date.set(Calendar.MILLISECOND, 0);
return date;
}
WebSphere 6.1.0.21 with EJB3.0 pack, ORACLE version has been provided
earlier (10.2.0.3 as I remember).
Can't imagine what else can follow openJPA to this strange behavior...
Kevin Sutter wrote:
>
> Hi Mikhail,
> If you can believe this, I still can not reproduce the problem. What
> exactly does your util.resetTime() method do?
>
> I have been trying your scenario with old and new versions of OpenJPA. I
> even went back and used the same JVM (IBM JDK 5sr6b). Still no luck.
>
> I can't any references in the spec or the OpenJPA documentation that
> restricts the code within getters and setters, but we do document how we
> proxy Date classes (and other similar types) so that we can more easily
> detect updates to these fields. You have shown how this affects your
> usage. Now, we just need to get the development team to be able to
> reproduce it so that we can figure out the root cause.
>
> Since it sounds like you have done much experimentation with this, do you
> have a small example or project that demonstrates this problem?
>
> Thanks!
> Kevin
>
> On Fri, Jul 17, 2009 at 7:50 AM, Kevin Sutter <kw...@gmail.com> wrote:
>
>> Mikhail,
>> Great detective work. I thought I had verified that this didn't matter,
>> but based on Mike's note below, I didn't actually replace the Date field
>> with my helper method. That must have been the trick with reproducing
>> the
>> problem. I will try that out in my environment when I get to work and
>> let
>> you know.
>>
>> Thanks!
>> Kevin
>>
>>
>> On Fri, Jul 17, 2009 at 6:57 AM, Michael Dick
>> <mi...@gmail.com>wrote:
>>
>>> I'm coming to this thread late (might not have all the info). OpenJPA
>>> proxy's Date types and I'd guess this is a problem with replacing the
>>> proxy.
>>> Does the problem exist if you modify the existing data object instead of
>>> creating a new one?
>>>
>>> -mike
>>>
>>> On Fri, Jul 17, 2009 at 2:03 AM, om <mi...@ubs.com> wrote:
>>>
>>> >
>>> > Hi Kevin, Ravi,
>>> >
>>> > Thank you very much for paying close attention to my problem. The
>>> issue
>>> has
>>> > been found and fixed due to your last messages. openJPA stopped
>>> generating
>>> > additional requests when I eliminated Util.resetTime(date) from
>>> setDate()
>>> > method. Since I couldn't imagine that it might somehow affect
>>> generation
>>> > process, I left this invocation while trying to simplify Account
>>> object
>>> > earlier. So, when I substituted
>>> > this.date = Util.resetTime(date);
>>> > with
>>> > this.date = date;
>>> >
>>> > in method
>>> > public void setDate(Calendar date)
>>> >
>>> > it started working fine.
>>> >
>>> > Could anybody please let me know if it's an openJPA known restriction
>>> (not
>>> > to use other methods in getters and setters), or a bug?
>>> >
>>> >
>>> > Kevin Sutter wrote:
>>> > >
>>> > > Doesn't seem to apply. I have also reproduced that error message
>>> with
>>> my
>>> > > testing, but I still haven't reproduced Mikhail's problem. Next
>>> option
>>> > is
>>> > > to try Oracle...
>>> > >
>>> > > On Thu, Jul 16, 2009 at 11:49 AM, Ravi Palacherla <
>>> > > ravi.palacherla@oracle.com> wrote:
>>> > >
>>> > >> Hi Kevin,
>>> > >>
>>> > >> I see the following in the log:
>>> > >>
>>> > >> [7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93
>>> MainPersistence
>>> > >> WARN [WebContainer : 0] openjpa.Enhance - [Possible violation of
>>> > >> subclassing contract detected while processing persistent field
>>> > >> com.ubs.n3.persistence.Account.date, declared in null. Are you sure
>>> you
>>> > >> are
>>> > >> obeying the OpenJPA requirements? Details: The setter for field
>>> date
>>> > does
>>> > >> not obey OpenJPAs subclassing restrictions. Setters must assign the
>>> > >> passed-in parameter to a single field in the object.]
>>> > >>
>>> > >> Do you have any idea what it means ?
>>> > >> Could it be related to this issue ?
>>> > >>
>>> > >> Regards,
>>> > >> Ravi.
>>> > >>
>>> > >> -----Original Message-----
>>> > >> From: Kevin Sutter [mailto:kwsutter@gmail.com]
>>> > >> Sent: Thursday, July 16, 2009 7:46 AM
>>> > >> To: users@openjpa.apache.org
>>> > >> Subject: Re: openJPA generates select per row - impossible to use
>>> for
>>> > >> simple select statements
>>> > >>
>>> > >> :-) Totally agree that it doesn't make sense. I also noticed that
>>> the
>>> > >> cur_code field is not re-queried. Still investigating...
>>> > >>
>>> > >> On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
>>> > >> Mikhail.Ostryanin@ubs.com> wrote:
>>> > >>
>>> > >> >
>>> > >> > Hi!
>>> > >> >
>>> > >> > Thank you for response!
>>> > >> >
>>> > >> > You're right, this log file was produced by last openJPA 2.0
>>> > >> > implementation linked to the application. But I have the same
>>> problem
>>> > >> > (generating additional select statements by primary key) with
>>> OpenJPA
>>> > >> > embedded in WebSphere, as well as WebSphere JPA itself ( as I
>>> know
>>> > it's
>>> > >> > enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1
>>> also.
>>> > >> >
>>> > >> > Anyway, problem still exists. What is most strange is that all
>>> > >> > additional queries do not include field cur_code :
>>> > >> >
>>> > >> > executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name,
>>> > t0.acc_seq,
>>> > >> > t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
>>> > >> >
>>> > >> > openJPA somehow decides that there's no need in querying
>>> cur_code,
>>> but
>>> > >> > it should query acc_name and some other fields. This logic does
>>> not
>>> > >> have
>>> > >> > explicit comprehension, since both fields are declared and used
>>> same
>>> > >> way
>>> > >> > in Account object.
>>> > >> >
>>> > >> > Best regards,
>>> > >> > Mikhail V. Ostryanin
>>> > >> > Sr.Developer/Analyst
>>> > >> > UBS, Moscow
>>> > >> > Tel: +7 495 648 22 14
>>> > >> > Mikhail.Ostryanin@UBS.com
>>> > >> >
>>> > >> > -----Original Message-----
>>> > >> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
>>> > >> > Sent: Thursday, July 16, 2009 5:20 PM
>>> > >> > To: users@openjpa.apache.org
>>> > >> > Subject: Re: openJPA generates select per row - impossible to use
>>> for
>>> > >> > simple select statements
>>> > >> >
>>> > >> > Hi Mikhail,
>>> > >> > Your log file is showing at least one difference from my
>>> environment.
>>> > >> > It
>>> > >> > looks like you are (accidentally) using the subclassing support
>>> for
>>> > >> > enhancement per this log statement:
>>> > >> >
>>> > >> > [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31
>>> > MainPersistence
>>> > >> > INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for
>>> > >> > "[class
>>> > >> > com.ubs.n3.persistence.ReportBond, class
>>> > >> com.ubs.n3.persistence.Account,
>>> > >> > class com.ubs.n3.persistence.N3Property]". This means that your
>>> > >> > application
>>> > >> > will be less efficient and will consume more memory than it would
>>> if
>>> > >> you
>>> > >> > ran
>>> > >> > the OpenJPA enhancer. Additionally, lazy loading will not be
>>> available
>>> > >> > for
>>> > >> > one-to-one and many-to-one persistent attributes in types using
>>> field
>>> > >> > access; they will be loaded eagerly instead.
>>> > >> >
>>> > >> > I thought I had asked about what type of enhancement processing
>>> you
>>> > >> were
>>> > >> > using, but maybe that was a different forum posting... You can
>>> find
>>> > >> out
>>> > >> > more about OpenJPA's enhancement processing here [1]. In a
>>> nutshell,
>>> > >> > the
>>> > >> > subclassing support is not meant for production use. It's meant
>>> for
>>> > >> > some
>>> > >> > simple, out of the box examples just to get people started. Real
>>> > usage
>>> > >> > of
>>> > >> > OpenJPA would use one of the enhancement processes.
>>> > >> >
>>> > >> > What's interesting is that you mention that you are using OpenJPA
>>> > >> within
>>> > >> > WebSphere. The WebSphere packaged version of OpenJPA turns off
>>> this
>>> > >> > subclassing support. If your applicaiton's processing should
>>> take
>>> you
>>> > >> > into
>>> > >> > the subclassing support, an error message should be logged to let
>>> you
>>> > >> > know
>>> > >> > of this condition. But, maybe you are just using OpenJPA as a
>>> shared
>>> > >> > library or an applicaiton library. In that case, the default,
>>> > >> > last-ditch
>>> > >> > attempt at enhancement is the subclassing support.
>>> > >> >
>>> > >> > I'm also not prepared to say that this is definitely your
>>> problem.
>>> > I'm
>>> > >> > waiting for my development environment to boot up, so I will try
>>> it
>>> > out
>>> > >> > shortly. But, anytime that I see subclassing with an error
>>> condition,
>>> > >> > it's
>>> > >> > been a common culprit. I just wanted to get this bit of
>>> information
>>> > >> out
>>> > >> > to
>>> > >> > you so that maybe we can try out variations at the same time.
>>> > >> >
>>> > >> > Good luck,
>>> > >> > Kevin
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> > [1]
>>> > >> >
>>> > >>
>>> >
>>> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
>>> > >> > l
>>> > >> >
>>> > >> > On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com>
>>> > wrote:
>>> > >> >
>>> > >> > >
>>> > >> > > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
>>> > >> > >
>>> > >> > > Hi All,
>>> > >> > >
>>> > >> > > Thank you very much for paying attention to my problem. In
>>> spite
>>> of
>>> > >> it
>>> > >> > > works
>>> > >> > > with Hibernate, I don't like the idea to use another JPA and
>>> have
>>> > >> > pretty
>>> > >> > > many additional libs on board. I would like to fix the issue
>>> with
>>> > >> > OpenJPA
>>> > >> > > and use it since it's embedded in WebSphere server, at least.
>>> > >> > >
>>> > >> > > The code is extremely simple and clear. Stateless bean just
>>> returns
>>> > >> > > query.getResultList() to struts2 action , which puts it in
>>> request
>>> > >> > object
>>> > >> > > for displaytag grid. The whole time spends in
>>> query.getResultList()
>>> > >> > method.
>>> > >> > >
>>> > >> > > I've tried once more to remove IFilterTO and Map from Account
>>> > object,
>>> > >> > but
>>> > >> > > with no result.
>>> > >> > >
>>> > >> > > I put asterisks before and after query.getResultList(),
>>> switched
>>> on
>>> > >> > > runtime
>>> > >> > > trace, and attached result log. It's pretty detailed, with many
>>> > >> > openjpa
>>> > >> > > runtime parameters and actions, may be somebody will be able to
>>> > >> > determine
>>> > >> > > what is happening...
>>> > >> > >
>>> > >> > > Database is ORACLE10, detailed version is present in attached
>>> log
>>> > >> file
>>> > >> > -
>>> > >> > > openJPA determined it correctly. Tables are created
>>> automatically
>>> by
>>> > >> > > OpenJPA
>>> > >> > > using the following property in persistence.xml :
>>> > >> > >
>>> > >> > > <properties>
>>> > >> > >
>>> > >> > > <property name="openjpa.jdbc.SynchronizeMappings"
>>> > >> > > value="buildSchema"/>
>>> > >> > >
>>> > >> > > </properties>
>>> > >> > >
>>> > >> > >
>>> > >> > >
>>> > >> > > IFilterTO interface just has two methods , nothing special :
>>> > >> > >
>>> > >> > > public interface IFilterTO {
>>> > >> > > void setValue( String key, String value );
>>> > >> > > String getValue( String key );
>>> > >> > > }
>>> > >> > >
>>> > >> > > Thank you all in advance for your help.
>>> > >> > >
>>> > >> > > Mikhail
>>> > >> > >
>>> > >> > >
>>> > >> > > Craig L Russell wrote:
>>> > >> > > >
>>> > >> > > > Hi,
>>> > >> > > >
>>> > >> > > > Could I ask again what the code is doing, following the
>>> > >> > > > query.getResultList() ?
>>> > >> > > >
>>> > >> > > > Where is the list of results being used? Are the results
>>> being
>>> > >> > > > serialized or detached?
>>> > >> > > >
>>> > >> > > > Thanks,
>>> > >> > > >
>>> > >> > > > Craig
>>> > >> > > >
>>> > >> > > > On Jul 15, 2009, at 12:19 AM, om wrote:
>>> > >> > > >
>>> > >> > > >>
>>> > >> > > >> Hi All!
>>> > >> > > >>
>>> > >> > > >> I'm new in openJPA, and didn't manage to get over the
>>> problem
>>> > with
>>> > >> > > >> simple
>>> > >> > > >> select statement for one object after a few days of
>>> > investigation.
>>> > >> > > >> Please
>>> > >> > > >> help!
>>> > >> > > >>
>>> > >> > > >> For simple select from one object, OpenJPA ( same strategy
>>> for
>>> > >> 1.0,
>>> > >> > > >> 1.2.1,
>>> > >> > > >> 2.0 ) fist generates right query to retrieve all rows and
>>> fields,
>>> > >> > > >> and then
>>> > >> > > >> start generating query per object by primary key.
>>> > >> > > >>
>>> > >> > > >> Code :
>>> > >> > > >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM
>>> > >> > Account
>>> > >> > > >> AS a
>>> > >> > > >> WHERE a.date = :date ");
>>> > >> > > >> PersistenceProviderImpl impl = new
>>> > PersistenceProviderImpl();
>>> > >> > > >> OpenJPAEntityManagerFactory fac =
>>> > >> > > >> impl.createEntityManagerFactory("MainPersistence",
>>> > >> > > >> System.getProperties());
>>> > >> > > >> OpenJPAEntityManager man = fac.createEntityManager();
>>> > >> > > >>
>>> > >> > > >> Query query = man.createQuery(queryBuf.toString());
>>> > >> > > >> query.setParameter("date", reportDate);
>>> > >> > > >> List res = query.getResultList();
>>> > >> > > >>
>>> > >> > > >>
>>> > >> > > >> LOG TRACE
>>> > >> > > >>
>>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>>> > >> > > >> openjpa.Runtime -
>>> > >> > > >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is
>>> > cached
>>> > >> > > >> as target
>>> > >> > > >> query "null"
>>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>>> > >> > > >> openjpa.Query -
>>> > >> > > >> Executing query: [SELECT a FROM Account AS a WHERE a.date =
>>> > :date]
>>> > >> > > >> with
>>> > >> > > >> parameters: {date=java.util.GregorianCalendar[]}
>>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>>> > >> > > >> openjpa.jdbc.SQL
>>> > >> > > >> - <t 1495423266, conn 1329090360> executing prepstmnt
>>> 1388597956
>>> > >> > > >> SELECT
>>> > >> > > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask,
>>> > t0.acc_name,
>>> > >> > > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
>>> > >> > > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
>>> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>>> > >> > > >> openjpa.jdbc.SQL -
>>> > >> > > >> <t 1495423266, conn 1329090360> [78 ms] spent
>>> > >> > > >>
>>> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>>> > >> > > >> openjpa.jdbc.SQL -
>>> > >> > > >> <t 1495423266, conn 1329090360> executing prepstmnt
>>> 139855958
>>> > >> > SELECT
>>> > >> > > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0
>>> WHERE
>>> > >> > > >> t0.id = ?
>>> > >> > > >> [params=(long) 328]
>>> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>>> > >> > > >> [WebContainer : 2]
>>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
>>> spent
>>> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>>> > >> > > >> [WebContainer : 2]
>>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
>>> > >> > prepstmnt
>>> > >> > > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value
>>> FROM
>>> > >> > > >> ACCOUNT t0
>>> > >> > > >> WHERE t0.id = ? [params=(long) 329]
>>> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>>> > >> > > >> [WebContainer : 2]
>>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
>>> spent
>>> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>>> > >> > > >> [WebContainer : 2]
>>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
>>> > >> > prepstmnt
>>> > >> > > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value
>>> FROM
>>> > >> > > >> ACCOUNT t0
>>> > >> > > >> WHERE t0.id = ? [params=(long) 330]
>>> > >> > > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
>>> > >> > > >> [WebContainer : 2]
>>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
>>> spent
>>> > >> > > >> ......................................
>>> > >> > > >>
>>> > >> > > >>
>>> > >> > > >> I need just list of detached objects to show it in grid. As
>>> it's
>>> > >> > > >> seen from
>>> > >> > > >> log trace above, first query is enough to return all
>>> necessary
>>> > >> > > >> objects and
>>> > >> > > >> fields.
>>> > >> > > >> Why OpenJPA makes select per object after that? In this case
>>> > >> simple
>>> > >> > > >> code
>>> > >> > > >> above works 37 seconds for retrieving 440 rows, since same
>>> jdbc
>>> > >> > > >> select and
>>> > >> > > >> wrap works 1.5 sec. I've tried different query hints and a
>>> few
>>> > >> > openjpa
>>> > >> > > >> versions, but with no result.
>>> > >> > > >>
>>> > >> > > >>
>>> > >> > > >> --
>>> > >> > > >> View this message in context:
>>> > >> > > >>
>>> > >> > >
>>> > >> >
>>> > >>
>>> >
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
>>> > >> > e-for-simple-select-statements-tp3261512p3261512.html<
>>> > >>
>>> >
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html
>>> > >> >
>>> > >> > > >> Sent from the OpenJPA Users mailing list archive at
>>> Nabble.com.
>>> > >> > > >
>>> > >> > > > Craig L Russell
>>> > >> > > > Architect, Sun Java Enterprise System
>>> http://db.apache.org/jdo
>>> > >> > > > 408 276-5638 mailto:Craig.Russell@sun.com
>>> > >> > > > P.S. A good JDO? O, Gasp!
>>> > >> > > >
>>> > >> > > >
>>> > >> > > >
>>> > >> > > >
>>> > >> > >
>>> > >> > > --
>>> > >> > > View this message in context:
>>> > >> > >
>>> > >> >
>>> > >>
>>> >
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
>>> > >> > e-for-simple-select-statements-tp3261512p3267829.html<
>>> > >>
>>> >
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html
>>> > >> >
>>> > >> > > Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>> > >> > >
>>> > >> > Visit our website at http://www.ubs.com
>>> > >> >
>>> > >> > This message contains confidential information and is intended
>>> only
>>> > >> > for the individual named. If you are not the named addressee you
>>> > >> > should not disseminate, distribute or copy this e-mail. Please
>>> > >> > notify the sender immediately by e-mail if you have received this
>>> > >> > e-mail by mistake and delete this e-mail from your system.
>>> > >> >
>>> > >> > E-mails are not encrypted and cannot be guaranteed to be secure
>>> or
>>> > >> > error-free as information could be intercepted, corrupted, lost,
>>> > >> > destroyed, arrive late or incomplete, or contain viruses. The
>>> sender
>>> > >> > therefore does not accept liability for any errors or omissions
>>> in
>>> the
>>> > >> > contents of this message which arise as a result of e-mail
>>> > >> transmission.
>>> > >> > If verification is required please request a hard-copy version.
>>> This
>>> > >> > message is provided for informational purposes and should not be
>>> > >> > construed as a solicitation or offer to buy or sell any
>>> securities
>>> > >> > or related financial instruments.
>>> > >> >
>>> > >> >
>>> > >> > UBS reserves the right to retain all messages. Messages are
>>> protected
>>> > >> > and accessed only in legally justified cases.
>>> > >> >
>>> > >>
>>> > >
>>> > >
>>> >
>>> > --
>>> > View this message in context:
>>> >
>>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3273854.html
>>> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>> >
>>>
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3289150.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Mikhail,
If you can believe this, I still can not reproduce the problem. What
exactly does your util.resetTime() method do?
I have been trying your scenario with old and new versions of OpenJPA. I
even went back and used the same JVM (IBM JDK 5sr6b). Still no luck.
I can't any references in the spec or the OpenJPA documentation that
restricts the code within getters and setters, but we do document how we
proxy Date classes (and other similar types) so that we can more easily
detect updates to these fields. You have shown how this affects your
usage. Now, we just need to get the development team to be able to
reproduce it so that we can figure out the root cause.
Since it sounds like you have done much experimentation with this, do you
have a small example or project that demonstrates this problem?
Thanks!
Kevin
On Fri, Jul 17, 2009 at 7:50 AM, Kevin Sutter <kw...@gmail.com> wrote:
> Mikhail,
> Great detective work. I thought I had verified that this didn't matter,
> but based on Mike's note below, I didn't actually replace the Date field
> with my helper method. That must have been the trick with reproducing the
> problem. I will try that out in my environment when I get to work and let
> you know.
>
> Thanks!
> Kevin
>
>
> On Fri, Jul 17, 2009 at 6:57 AM, Michael Dick <mi...@gmail.com>wrote:
>
>> I'm coming to this thread late (might not have all the info). OpenJPA
>> proxy's Date types and I'd guess this is a problem with replacing the
>> proxy.
>> Does the problem exist if you modify the existing data object instead of
>> creating a new one?
>>
>> -mike
>>
>> On Fri, Jul 17, 2009 at 2:03 AM, om <mi...@ubs.com> wrote:
>>
>> >
>> > Hi Kevin, Ravi,
>> >
>> > Thank you very much for paying close attention to my problem. The issue
>> has
>> > been found and fixed due to your last messages. openJPA stopped
>> generating
>> > additional requests when I eliminated Util.resetTime(date) from
>> setDate()
>> > method. Since I couldn't imagine that it might somehow affect generation
>> > process, I left this invocation while trying to simplify Account object
>> > earlier. So, when I substituted
>> > this.date = Util.resetTime(date);
>> > with
>> > this.date = date;
>> >
>> > in method
>> > public void setDate(Calendar date)
>> >
>> > it started working fine.
>> >
>> > Could anybody please let me know if it's an openJPA known restriction
>> (not
>> > to use other methods in getters and setters), or a bug?
>> >
>> >
>> > Kevin Sutter wrote:
>> > >
>> > > Doesn't seem to apply. I have also reproduced that error message with
>> my
>> > > testing, but I still haven't reproduced Mikhail's problem. Next
>> option
>> > is
>> > > to try Oracle...
>> > >
>> > > On Thu, Jul 16, 2009 at 11:49 AM, Ravi Palacherla <
>> > > ravi.palacherla@oracle.com> wrote:
>> > >
>> > >> Hi Kevin,
>> > >>
>> > >> I see the following in the log:
>> > >>
>> > >> [7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93
>> MainPersistence
>> > >> WARN [WebContainer : 0] openjpa.Enhance - [Possible violation of
>> > >> subclassing contract detected while processing persistent field
>> > >> com.ubs.n3.persistence.Account.date, declared in null. Are you sure
>> you
>> > >> are
>> > >> obeying the OpenJPA requirements? Details: The setter for field date
>> > does
>> > >> not obey OpenJPAs subclassing restrictions. Setters must assign the
>> > >> passed-in parameter to a single field in the object.]
>> > >>
>> > >> Do you have any idea what it means ?
>> > >> Could it be related to this issue ?
>> > >>
>> > >> Regards,
>> > >> Ravi.
>> > >>
>> > >> -----Original Message-----
>> > >> From: Kevin Sutter [mailto:kwsutter@gmail.com]
>> > >> Sent: Thursday, July 16, 2009 7:46 AM
>> > >> To: users@openjpa.apache.org
>> > >> Subject: Re: openJPA generates select per row - impossible to use for
>> > >> simple select statements
>> > >>
>> > >> :-) Totally agree that it doesn't make sense. I also noticed that
>> the
>> > >> cur_code field is not re-queried. Still investigating...
>> > >>
>> > >> On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
>> > >> Mikhail.Ostryanin@ubs.com> wrote:
>> > >>
>> > >> >
>> > >> > Hi!
>> > >> >
>> > >> > Thank you for response!
>> > >> >
>> > >> > You're right, this log file was produced by last openJPA 2.0
>> > >> > implementation linked to the application. But I have the same
>> problem
>> > >> > (generating additional select statements by primary key) with
>> OpenJPA
>> > >> > embedded in WebSphere, as well as WebSphere JPA itself ( as I know
>> > it's
>> > >> > enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1
>> also.
>> > >> >
>> > >> > Anyway, problem still exists. What is most strange is that all
>> > >> > additional queries do not include field cur_code :
>> > >> >
>> > >> > executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name,
>> > t0.acc_seq,
>> > >> > t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
>> > >> >
>> > >> > openJPA somehow decides that there's no need in querying cur_code,
>> but
>> > >> > it should query acc_name and some other fields. This logic does not
>> > >> have
>> > >> > explicit comprehension, since both fields are declared and used
>> same
>> > >> way
>> > >> > in Account object.
>> > >> >
>> > >> > Best regards,
>> > >> > Mikhail V. Ostryanin
>> > >> > Sr.Developer/Analyst
>> > >> > UBS, Moscow
>> > >> > Tel: +7 495 648 22 14
>> > >> > Mikhail.Ostryanin@UBS.com
>> > >> >
>> > >> > -----Original Message-----
>> > >> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
>> > >> > Sent: Thursday, July 16, 2009 5:20 PM
>> > >> > To: users@openjpa.apache.org
>> > >> > Subject: Re: openJPA generates select per row - impossible to use
>> for
>> > >> > simple select statements
>> > >> >
>> > >> > Hi Mikhail,
>> > >> > Your log file is showing at least one difference from my
>> environment.
>> > >> > It
>> > >> > looks like you are (accidentally) using the subclassing support for
>> > >> > enhancement per this log statement:
>> > >> >
>> > >> > [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31
>> > MainPersistence
>> > >> > INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for
>> > >> > "[class
>> > >> > com.ubs.n3.persistence.ReportBond, class
>> > >> com.ubs.n3.persistence.Account,
>> > >> > class com.ubs.n3.persistence.N3Property]". This means that your
>> > >> > application
>> > >> > will be less efficient and will consume more memory than it would
>> if
>> > >> you
>> > >> > ran
>> > >> > the OpenJPA enhancer. Additionally, lazy loading will not be
>> available
>> > >> > for
>> > >> > one-to-one and many-to-one persistent attributes in types using
>> field
>> > >> > access; they will be loaded eagerly instead.
>> > >> >
>> > >> > I thought I had asked about what type of enhancement processing you
>> > >> were
>> > >> > using, but maybe that was a different forum posting... You can
>> find
>> > >> out
>> > >> > more about OpenJPA's enhancement processing here [1]. In a
>> nutshell,
>> > >> > the
>> > >> > subclassing support is not meant for production use. It's meant
>> for
>> > >> > some
>> > >> > simple, out of the box examples just to get people started. Real
>> > usage
>> > >> > of
>> > >> > OpenJPA would use one of the enhancement processes.
>> > >> >
>> > >> > What's interesting is that you mention that you are using OpenJPA
>> > >> within
>> > >> > WebSphere. The WebSphere packaged version of OpenJPA turns off
>> this
>> > >> > subclassing support. If your applicaiton's processing should take
>> you
>> > >> > into
>> > >> > the subclassing support, an error message should be logged to let
>> you
>> > >> > know
>> > >> > of this condition. But, maybe you are just using OpenJPA as a
>> shared
>> > >> > library or an applicaiton library. In that case, the default,
>> > >> > last-ditch
>> > >> > attempt at enhancement is the subclassing support.
>> > >> >
>> > >> > I'm also not prepared to say that this is definitely your problem.
>> > I'm
>> > >> > waiting for my development environment to boot up, so I will try it
>> > out
>> > >> > shortly. But, anytime that I see subclassing with an error
>> condition,
>> > >> > it's
>> > >> > been a common culprit. I just wanted to get this bit of
>> information
>> > >> out
>> > >> > to
>> > >> > you so that maybe we can try out variations at the same time.
>> > >> >
>> > >> > Good luck,
>> > >> > Kevin
>> > >> >
>> > >> >
>> > >> >
>> > >> > [1]
>> > >> >
>> > >>
>> >
>> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
>> > >> > l
>> > >> >
>> > >> > On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com>
>> > wrote:
>> > >> >
>> > >> > >
>> > >> > > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
>> > >> > >
>> > >> > > Hi All,
>> > >> > >
>> > >> > > Thank you very much for paying attention to my problem. In spite
>> of
>> > >> it
>> > >> > > works
>> > >> > > with Hibernate, I don't like the idea to use another JPA and have
>> > >> > pretty
>> > >> > > many additional libs on board. I would like to fix the issue with
>> > >> > OpenJPA
>> > >> > > and use it since it's embedded in WebSphere server, at least.
>> > >> > >
>> > >> > > The code is extremely simple and clear. Stateless bean just
>> returns
>> > >> > > query.getResultList() to struts2 action , which puts it in
>> request
>> > >> > object
>> > >> > > for displaytag grid. The whole time spends in
>> query.getResultList()
>> > >> > method.
>> > >> > >
>> > >> > > I've tried once more to remove IFilterTO and Map from Account
>> > object,
>> > >> > but
>> > >> > > with no result.
>> > >> > >
>> > >> > > I put asterisks before and after query.getResultList(), switched
>> on
>> > >> > > runtime
>> > >> > > trace, and attached result log. It's pretty detailed, with many
>> > >> > openjpa
>> > >> > > runtime parameters and actions, may be somebody will be able to
>> > >> > determine
>> > >> > > what is happening...
>> > >> > >
>> > >> > > Database is ORACLE10, detailed version is present in attached log
>> > >> file
>> > >> > -
>> > >> > > openJPA determined it correctly. Tables are created automatically
>> by
>> > >> > > OpenJPA
>> > >> > > using the following property in persistence.xml :
>> > >> > >
>> > >> > > <properties>
>> > >> > >
>> > >> > > <property name="openjpa.jdbc.SynchronizeMappings"
>> > >> > > value="buildSchema"/>
>> > >> > >
>> > >> > > </properties>
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > IFilterTO interface just has two methods , nothing special :
>> > >> > >
>> > >> > > public interface IFilterTO {
>> > >> > > void setValue( String key, String value );
>> > >> > > String getValue( String key );
>> > >> > > }
>> > >> > >
>> > >> > > Thank you all in advance for your help.
>> > >> > >
>> > >> > > Mikhail
>> > >> > >
>> > >> > >
>> > >> > > Craig L Russell wrote:
>> > >> > > >
>> > >> > > > Hi,
>> > >> > > >
>> > >> > > > Could I ask again what the code is doing, following the
>> > >> > > > query.getResultList() ?
>> > >> > > >
>> > >> > > > Where is the list of results being used? Are the results being
>> > >> > > > serialized or detached?
>> > >> > > >
>> > >> > > > Thanks,
>> > >> > > >
>> > >> > > > Craig
>> > >> > > >
>> > >> > > > On Jul 15, 2009, at 12:19 AM, om wrote:
>> > >> > > >
>> > >> > > >>
>> > >> > > >> Hi All!
>> > >> > > >>
>> > >> > > >> I'm new in openJPA, and didn't manage to get over the problem
>> > with
>> > >> > > >> simple
>> > >> > > >> select statement for one object after a few days of
>> > investigation.
>> > >> > > >> Please
>> > >> > > >> help!
>> > >> > > >>
>> > >> > > >> For simple select from one object, OpenJPA ( same strategy for
>> > >> 1.0,
>> > >> > > >> 1.2.1,
>> > >> > > >> 2.0 ) fist generates right query to retrieve all rows and
>> fields,
>> > >> > > >> and then
>> > >> > > >> start generating query per object by primary key.
>> > >> > > >>
>> > >> > > >> Code :
>> > >> > > >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM
>> > >> > Account
>> > >> > > >> AS a
>> > >> > > >> WHERE a.date = :date ");
>> > >> > > >> PersistenceProviderImpl impl = new
>> > PersistenceProviderImpl();
>> > >> > > >> OpenJPAEntityManagerFactory fac =
>> > >> > > >> impl.createEntityManagerFactory("MainPersistence",
>> > >> > > >> System.getProperties());
>> > >> > > >> OpenJPAEntityManager man = fac.createEntityManager();
>> > >> > > >>
>> > >> > > >> Query query = man.createQuery(queryBuf.toString());
>> > >> > > >> query.setParameter("date", reportDate);
>> > >> > > >> List res = query.getResultList();
>> > >> > > >>
>> > >> > > >>
>> > >> > > >> LOG TRACE
>> > >> > > >>
>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> > >> > > >> openjpa.Runtime -
>> > >> > > >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is
>> > cached
>> > >> > > >> as target
>> > >> > > >> query "null"
>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> > >> > > >> openjpa.Query -
>> > >> > > >> Executing query: [SELECT a FROM Account AS a WHERE a.date =
>> > :date]
>> > >> > > >> with
>> > >> > > >> parameters: {date=java.util.GregorianCalendar[]}
>> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> > >> > > >> openjpa.jdbc.SQL
>> > >> > > >> - <t 1495423266, conn 1329090360> executing prepstmnt
>> 1388597956
>> > >> > > >> SELECT
>> > >> > > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask,
>> > t0.acc_name,
>> > >> > > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
>> > >> > > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
>> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> > >> > > >> openjpa.jdbc.SQL -
>> > >> > > >> <t 1495423266, conn 1329090360> [78 ms] spent
>> > >> > > >>
>> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> > >> > > >> openjpa.jdbc.SQL -
>> > >> > > >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958
>> > >> > SELECT
>> > >> > > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0
>> WHERE
>> > >> > > >> t0.id = ?
>> > >> > > >> [params=(long) 328]
>> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>> > >> > > >> [WebContainer : 2]
>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
>> spent
>> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>> > >> > > >> [WebContainer : 2]
>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
>> > >> > prepstmnt
>> > >> > > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value
>> FROM
>> > >> > > >> ACCOUNT t0
>> > >> > > >> WHERE t0.id = ? [params=(long) 329]
>> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>> > >> > > >> [WebContainer : 2]
>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
>> spent
>> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>> > >> > > >> [WebContainer : 2]
>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
>> > >> > prepstmnt
>> > >> > > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value
>> FROM
>> > >> > > >> ACCOUNT t0
>> > >> > > >> WHERE t0.id = ? [params=(long) 330]
>> > >> > > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
>> > >> > > >> [WebContainer : 2]
>> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
>> spent
>> > >> > > >> ......................................
>> > >> > > >>
>> > >> > > >>
>> > >> > > >> I need just list of detached objects to show it in grid. As
>> it's
>> > >> > > >> seen from
>> > >> > > >> log trace above, first query is enough to return all necessary
>> > >> > > >> objects and
>> > >> > > >> fields.
>> > >> > > >> Why OpenJPA makes select per object after that? In this case
>> > >> simple
>> > >> > > >> code
>> > >> > > >> above works 37 seconds for retrieving 440 rows, since same
>> jdbc
>> > >> > > >> select and
>> > >> > > >> wrap works 1.5 sec. I've tried different query hints and a few
>> > >> > openjpa
>> > >> > > >> versions, but with no result.
>> > >> > > >>
>> > >> > > >>
>> > >> > > >> --
>> > >> > > >> View this message in context:
>> > >> > > >>
>> > >> > >
>> > >> >
>> > >>
>> >
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
>> > >> > e-for-simple-select-statements-tp3261512p3261512.html<
>> > >>
>> >
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html
>> > >> >
>> > >> > > >> Sent from the OpenJPA Users mailing list archive at
>> Nabble.com.
>> > >> > > >
>> > >> > > > Craig L Russell
>> > >> > > > Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> > >> > > > 408 276-5638 mailto:Craig.Russell@sun.com
>> > >> > > > P.S. A good JDO? O, Gasp!
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > >
>> > >> > > --
>> > >> > > View this message in context:
>> > >> > >
>> > >> >
>> > >>
>> >
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
>> > >> > e-for-simple-select-statements-tp3261512p3267829.html<
>> > >>
>> >
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html
>> > >> >
>> > >> > > Sent from the OpenJPA Users mailing list archive at Nabble.com.
>> > >> > >
>> > >> > Visit our website at http://www.ubs.com
>> > >> >
>> > >> > This message contains confidential information and is intended only
>> > >> > for the individual named. If you are not the named addressee you
>> > >> > should not disseminate, distribute or copy this e-mail. Please
>> > >> > notify the sender immediately by e-mail if you have received this
>> > >> > e-mail by mistake and delete this e-mail from your system.
>> > >> >
>> > >> > E-mails are not encrypted and cannot be guaranteed to be secure or
>> > >> > error-free as information could be intercepted, corrupted, lost,
>> > >> > destroyed, arrive late or incomplete, or contain viruses. The
>> sender
>> > >> > therefore does not accept liability for any errors or omissions in
>> the
>> > >> > contents of this message which arise as a result of e-mail
>> > >> transmission.
>> > >> > If verification is required please request a hard-copy version.
>> This
>> > >> > message is provided for informational purposes and should not be
>> > >> > construed as a solicitation or offer to buy or sell any securities
>> > >> > or related financial instruments.
>> > >> >
>> > >> >
>> > >> > UBS reserves the right to retain all messages. Messages are
>> protected
>> > >> > and accessed only in legally justified cases.
>> > >> >
>> > >>
>> > >
>> > >
>> >
>> > --
>> > View this message in context:
>> >
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3273854.html
>> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
>> >
>>
>
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
Mikhail,
Great detective work. I thought I had verified that this didn't matter, but
based on Mike's note below, I didn't actually replace the Date field with my
helper method. That must have been the trick with reproducing the problem.
I will try that out in my environment when I get to work and let you know.
Thanks!
Kevin
On Fri, Jul 17, 2009 at 6:57 AM, Michael Dick <mi...@gmail.com>wrote:
> I'm coming to this thread late (might not have all the info). OpenJPA
> proxy's Date types and I'd guess this is a problem with replacing the
> proxy.
> Does the problem exist if you modify the existing data object instead of
> creating a new one?
>
> -mike
>
> On Fri, Jul 17, 2009 at 2:03 AM, om <mi...@ubs.com> wrote:
>
> >
> > Hi Kevin, Ravi,
> >
> > Thank you very much for paying close attention to my problem. The issue
> has
> > been found and fixed due to your last messages. openJPA stopped
> generating
> > additional requests when I eliminated Util.resetTime(date) from setDate()
> > method. Since I couldn't imagine that it might somehow affect generation
> > process, I left this invocation while trying to simplify Account object
> > earlier. So, when I substituted
> > this.date = Util.resetTime(date);
> > with
> > this.date = date;
> >
> > in method
> > public void setDate(Calendar date)
> >
> > it started working fine.
> >
> > Could anybody please let me know if it's an openJPA known restriction
> (not
> > to use other methods in getters and setters), or a bug?
> >
> >
> > Kevin Sutter wrote:
> > >
> > > Doesn't seem to apply. I have also reproduced that error message with
> my
> > > testing, but I still haven't reproduced Mikhail's problem. Next option
> > is
> > > to try Oracle...
> > >
> > > On Thu, Jul 16, 2009 at 11:49 AM, Ravi Palacherla <
> > > ravi.palacherla@oracle.com> wrote:
> > >
> > >> Hi Kevin,
> > >>
> > >> I see the following in the log:
> > >>
> > >> [7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93
> MainPersistence
> > >> WARN [WebContainer : 0] openjpa.Enhance - [Possible violation of
> > >> subclassing contract detected while processing persistent field
> > >> com.ubs.n3.persistence.Account.date, declared in null. Are you sure
> you
> > >> are
> > >> obeying the OpenJPA requirements? Details: The setter for field date
> > does
> > >> not obey OpenJPAs subclassing restrictions. Setters must assign the
> > >> passed-in parameter to a single field in the object.]
> > >>
> > >> Do you have any idea what it means ?
> > >> Could it be related to this issue ?
> > >>
> > >> Regards,
> > >> Ravi.
> > >>
> > >> -----Original Message-----
> > >> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> > >> Sent: Thursday, July 16, 2009 7:46 AM
> > >> To: users@openjpa.apache.org
> > >> Subject: Re: openJPA generates select per row - impossible to use for
> > >> simple select statements
> > >>
> > >> :-) Totally agree that it doesn't make sense. I also noticed that
> the
> > >> cur_code field is not re-queried. Still investigating...
> > >>
> > >> On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
> > >> Mikhail.Ostryanin@ubs.com> wrote:
> > >>
> > >> >
> > >> > Hi!
> > >> >
> > >> > Thank you for response!
> > >> >
> > >> > You're right, this log file was produced by last openJPA 2.0
> > >> > implementation linked to the application. But I have the same
> problem
> > >> > (generating additional select statements by primary key) with
> OpenJPA
> > >> > embedded in WebSphere, as well as WebSphere JPA itself ( as I know
> > it's
> > >> > enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1 also.
> > >> >
> > >> > Anyway, problem still exists. What is most strange is that all
> > >> > additional queries do not include field cur_code :
> > >> >
> > >> > executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name,
> > t0.acc_seq,
> > >> > t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
> > >> >
> > >> > openJPA somehow decides that there's no need in querying cur_code,
> but
> > >> > it should query acc_name and some other fields. This logic does not
> > >> have
> > >> > explicit comprehension, since both fields are declared and used same
> > >> way
> > >> > in Account object.
> > >> >
> > >> > Best regards,
> > >> > Mikhail V. Ostryanin
> > >> > Sr.Developer/Analyst
> > >> > UBS, Moscow
> > >> > Tel: +7 495 648 22 14
> > >> > Mikhail.Ostryanin@UBS.com
> > >> >
> > >> > -----Original Message-----
> > >> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
> > >> > Sent: Thursday, July 16, 2009 5:20 PM
> > >> > To: users@openjpa.apache.org
> > >> > Subject: Re: openJPA generates select per row - impossible to use
> for
> > >> > simple select statements
> > >> >
> > >> > Hi Mikhail,
> > >> > Your log file is showing at least one difference from my
> environment.
> > >> > It
> > >> > looks like you are (accidentally) using the subclassing support for
> > >> > enhancement per this log statement:
> > >> >
> > >> > [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31
> > MainPersistence
> > >> > INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for
> > >> > "[class
> > >> > com.ubs.n3.persistence.ReportBond, class
> > >> com.ubs.n3.persistence.Account,
> > >> > class com.ubs.n3.persistence.N3Property]". This means that your
> > >> > application
> > >> > will be less efficient and will consume more memory than it would if
> > >> you
> > >> > ran
> > >> > the OpenJPA enhancer. Additionally, lazy loading will not be
> available
> > >> > for
> > >> > one-to-one and many-to-one persistent attributes in types using
> field
> > >> > access; they will be loaded eagerly instead.
> > >> >
> > >> > I thought I had asked about what type of enhancement processing you
> > >> were
> > >> > using, but maybe that was a different forum posting... You can find
> > >> out
> > >> > more about OpenJPA's enhancement processing here [1]. In a
> nutshell,
> > >> > the
> > >> > subclassing support is not meant for production use. It's meant for
> > >> > some
> > >> > simple, out of the box examples just to get people started. Real
> > usage
> > >> > of
> > >> > OpenJPA would use one of the enhancement processes.
> > >> >
> > >> > What's interesting is that you mention that you are using OpenJPA
> > >> within
> > >> > WebSphere. The WebSphere packaged version of OpenJPA turns off this
> > >> > subclassing support. If your applicaiton's processing should take
> you
> > >> > into
> > >> > the subclassing support, an error message should be logged to let
> you
> > >> > know
> > >> > of this condition. But, maybe you are just using OpenJPA as a
> shared
> > >> > library or an applicaiton library. In that case, the default,
> > >> > last-ditch
> > >> > attempt at enhancement is the subclassing support.
> > >> >
> > >> > I'm also not prepared to say that this is definitely your problem.
> > I'm
> > >> > waiting for my development environment to boot up, so I will try it
> > out
> > >> > shortly. But, anytime that I see subclassing with an error
> condition,
> > >> > it's
> > >> > been a common culprit. I just wanted to get this bit of information
> > >> out
> > >> > to
> > >> > you so that maybe we can try out variations at the same time.
> > >> >
> > >> > Good luck,
> > >> > Kevin
> > >> >
> > >> >
> > >> >
> > >> > [1]
> > >> >
> > >>
> > http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
> > >> > l
> > >> >
> > >> > On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com>
> > wrote:
> > >> >
> > >> > >
> > >> > > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
> > >> > >
> > >> > > Hi All,
> > >> > >
> > >> > > Thank you very much for paying attention to my problem. In spite
> of
> > >> it
> > >> > > works
> > >> > > with Hibernate, I don't like the idea to use another JPA and have
> > >> > pretty
> > >> > > many additional libs on board. I would like to fix the issue with
> > >> > OpenJPA
> > >> > > and use it since it's embedded in WebSphere server, at least.
> > >> > >
> > >> > > The code is extremely simple and clear. Stateless bean just
> returns
> > >> > > query.getResultList() to struts2 action , which puts it in request
> > >> > object
> > >> > > for displaytag grid. The whole time spends in
> query.getResultList()
> > >> > method.
> > >> > >
> > >> > > I've tried once more to remove IFilterTO and Map from Account
> > object,
> > >> > but
> > >> > > with no result.
> > >> > >
> > >> > > I put asterisks before and after query.getResultList(), switched
> on
> > >> > > runtime
> > >> > > trace, and attached result log. It's pretty detailed, with many
> > >> > openjpa
> > >> > > runtime parameters and actions, may be somebody will be able to
> > >> > determine
> > >> > > what is happening...
> > >> > >
> > >> > > Database is ORACLE10, detailed version is present in attached log
> > >> file
> > >> > -
> > >> > > openJPA determined it correctly. Tables are created automatically
> by
> > >> > > OpenJPA
> > >> > > using the following property in persistence.xml :
> > >> > >
> > >> > > <properties>
> > >> > >
> > >> > > <property name="openjpa.jdbc.SynchronizeMappings"
> > >> > > value="buildSchema"/>
> > >> > >
> > >> > > </properties>
> > >> > >
> > >> > >
> > >> > >
> > >> > > IFilterTO interface just has two methods , nothing special :
> > >> > >
> > >> > > public interface IFilterTO {
> > >> > > void setValue( String key, String value );
> > >> > > String getValue( String key );
> > >> > > }
> > >> > >
> > >> > > Thank you all in advance for your help.
> > >> > >
> > >> > > Mikhail
> > >> > >
> > >> > >
> > >> > > Craig L Russell wrote:
> > >> > > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > Could I ask again what the code is doing, following the
> > >> > > > query.getResultList() ?
> > >> > > >
> > >> > > > Where is the list of results being used? Are the results being
> > >> > > > serialized or detached?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > > Craig
> > >> > > >
> > >> > > > On Jul 15, 2009, at 12:19 AM, om wrote:
> > >> > > >
> > >> > > >>
> > >> > > >> Hi All!
> > >> > > >>
> > >> > > >> I'm new in openJPA, and didn't manage to get over the problem
> > with
> > >> > > >> simple
> > >> > > >> select statement for one object after a few days of
> > investigation.
> > >> > > >> Please
> > >> > > >> help!
> > >> > > >>
> > >> > > >> For simple select from one object, OpenJPA ( same strategy for
> > >> 1.0,
> > >> > > >> 1.2.1,
> > >> > > >> 2.0 ) fist generates right query to retrieve all rows and
> fields,
> > >> > > >> and then
> > >> > > >> start generating query per object by primary key.
> > >> > > >>
> > >> > > >> Code :
> > >> > > >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM
> > >> > Account
> > >> > > >> AS a
> > >> > > >> WHERE a.date = :date ");
> > >> > > >> PersistenceProviderImpl impl = new
> > PersistenceProviderImpl();
> > >> > > >> OpenJPAEntityManagerFactory fac =
> > >> > > >> impl.createEntityManagerFactory("MainPersistence",
> > >> > > >> System.getProperties());
> > >> > > >> OpenJPAEntityManager man = fac.createEntityManager();
> > >> > > >>
> > >> > > >> Query query = man.createQuery(queryBuf.toString());
> > >> > > >> query.setParameter("date", reportDate);
> > >> > > >> List res = query.getResultList();
> > >> > > >>
> > >> > > >>
> > >> > > >> LOG TRACE
> > >> > > >>
> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > >> > > >> openjpa.Runtime -
> > >> > > >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is
> > cached
> > >> > > >> as target
> > >> > > >> query "null"
> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > >> > > >> openjpa.Query -
> > >> > > >> Executing query: [SELECT a FROM Account AS a WHERE a.date =
> > :date]
> > >> > > >> with
> > >> > > >> parameters: {date=java.util.GregorianCalendar[]}
> > >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > >> > > >> openjpa.jdbc.SQL
> > >> > > >> - <t 1495423266, conn 1329090360> executing prepstmnt
> 1388597956
> > >> > > >> SELECT
> > >> > > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask,
> > t0.acc_name,
> > >> > > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> > >> > > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> > >> > > >> openjpa.jdbc.SQL -
> > >> > > >> <t 1495423266, conn 1329090360> [78 ms] spent
> > >> > > >>
> > >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> > >> > > >> openjpa.jdbc.SQL -
> > >> > > >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958
> > >> > SELECT
> > >> > > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0
> WHERE
> > >> > > >> t0.id = ?
> > >> > > >> [params=(long) 328]
> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> > >> > > >> [WebContainer : 2]
> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
> spent
> > >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> > >> > > >> [WebContainer : 2]
> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> > >> > prepstmnt
> > >> > > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value
> FROM
> > >> > > >> ACCOUNT t0
> > >> > > >> WHERE t0.id = ? [params=(long) 329]
> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> > >> > > >> [WebContainer : 2]
> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
> spent
> > >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> > >> > > >> [WebContainer : 2]
> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> > >> > prepstmnt
> > >> > > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value
> FROM
> > >> > > >> ACCOUNT t0
> > >> > > >> WHERE t0.id = ? [params=(long) 330]
> > >> > > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
> > >> > > >> [WebContainer : 2]
> > >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms]
> spent
> > >> > > >> ......................................
> > >> > > >>
> > >> > > >>
> > >> > > >> I need just list of detached objects to show it in grid. As
> it's
> > >> > > >> seen from
> > >> > > >> log trace above, first query is enough to return all necessary
> > >> > > >> objects and
> > >> > > >> fields.
> > >> > > >> Why OpenJPA makes select per object after that? In this case
> > >> simple
> > >> > > >> code
> > >> > > >> above works 37 seconds for retrieving 440 rows, since same jdbc
> > >> > > >> select and
> > >> > > >> wrap works 1.5 sec. I've tried different query hints and a few
> > >> > openjpa
> > >> > > >> versions, but with no result.
> > >> > > >>
> > >> > > >>
> > >> > > >> --
> > >> > > >> View this message in context:
> > >> > > >>
> > >> > >
> > >> >
> > >>
> > http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> > >> > e-for-simple-select-statements-tp3261512p3261512.html<
> > >>
> >
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html
> > >> >
> > >> > > >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> > >> > > >
> > >> > > > Craig L Russell
> > >> > > > Architect, Sun Java Enterprise System http://db.apache.org/jdo
> > >> > > > 408 276-5638 mailto:Craig.Russell@sun.com
> > >> > > > P.S. A good JDO? O, Gasp!
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > >
> > >> > > --
> > >> > > View this message in context:
> > >> > >
> > >> >
> > >>
> > http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> > >> > e-for-simple-select-statements-tp3261512p3267829.html<
> > >>
> >
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html
> > >> >
> > >> > > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> > >> > >
> > >> > Visit our website at http://www.ubs.com
> > >> >
> > >> > This message contains confidential information and is intended only
> > >> > for the individual named. If you are not the named addressee you
> > >> > should not disseminate, distribute or copy this e-mail. Please
> > >> > notify the sender immediately by e-mail if you have received this
> > >> > e-mail by mistake and delete this e-mail from your system.
> > >> >
> > >> > E-mails are not encrypted and cannot be guaranteed to be secure or
> > >> > error-free as information could be intercepted, corrupted, lost,
> > >> > destroyed, arrive late or incomplete, or contain viruses. The
> sender
> > >> > therefore does not accept liability for any errors or omissions in
> the
> > >> > contents of this message which arise as a result of e-mail
> > >> transmission.
> > >> > If verification is required please request a hard-copy version.
> This
> > >> > message is provided for informational purposes and should not be
> > >> > construed as a solicitation or offer to buy or sell any securities
> > >> > or related financial instruments.
> > >> >
> > >> >
> > >> > UBS reserves the right to retain all messages. Messages are
> protected
> > >> > and accessed only in legally justified cases.
> > >> >
> > >>
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3273854.html
> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Michael Dick <mi...@gmail.com>.
I'm coming to this thread late (might not have all the info). OpenJPA
proxy's Date types and I'd guess this is a problem with replacing the proxy.
Does the problem exist if you modify the existing data object instead of
creating a new one?
-mike
On Fri, Jul 17, 2009 at 2:03 AM, om <mi...@ubs.com> wrote:
>
> Hi Kevin, Ravi,
>
> Thank you very much for paying close attention to my problem. The issue has
> been found and fixed due to your last messages. openJPA stopped generating
> additional requests when I eliminated Util.resetTime(date) from setDate()
> method. Since I couldn't imagine that it might somehow affect generation
> process, I left this invocation while trying to simplify Account object
> earlier. So, when I substituted
> this.date = Util.resetTime(date);
> with
> this.date = date;
>
> in method
> public void setDate(Calendar date)
>
> it started working fine.
>
> Could anybody please let me know if it's an openJPA known restriction (not
> to use other methods in getters and setters), or a bug?
>
>
> Kevin Sutter wrote:
> >
> > Doesn't seem to apply. I have also reproduced that error message with my
> > testing, but I still haven't reproduced Mikhail's problem. Next option
> is
> > to try Oracle...
> >
> > On Thu, Jul 16, 2009 at 11:49 AM, Ravi Palacherla <
> > ravi.palacherla@oracle.com> wrote:
> >
> >> Hi Kevin,
> >>
> >> I see the following in the log:
> >>
> >> [7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93 MainPersistence
> >> WARN [WebContainer : 0] openjpa.Enhance - [Possible violation of
> >> subclassing contract detected while processing persistent field
> >> com.ubs.n3.persistence.Account.date, declared in null. Are you sure you
> >> are
> >> obeying the OpenJPA requirements? Details: The setter for field date
> does
> >> not obey OpenJPAs subclassing restrictions. Setters must assign the
> >> passed-in parameter to a single field in the object.]
> >>
> >> Do you have any idea what it means ?
> >> Could it be related to this issue ?
> >>
> >> Regards,
> >> Ravi.
> >>
> >> -----Original Message-----
> >> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> >> Sent: Thursday, July 16, 2009 7:46 AM
> >> To: users@openjpa.apache.org
> >> Subject: Re: openJPA generates select per row - impossible to use for
> >> simple select statements
> >>
> >> :-) Totally agree that it doesn't make sense. I also noticed that the
> >> cur_code field is not re-queried. Still investigating...
> >>
> >> On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
> >> Mikhail.Ostryanin@ubs.com> wrote:
> >>
> >> >
> >> > Hi!
> >> >
> >> > Thank you for response!
> >> >
> >> > You're right, this log file was produced by last openJPA 2.0
> >> > implementation linked to the application. But I have the same problem
> >> > (generating additional select statements by primary key) with OpenJPA
> >> > embedded in WebSphere, as well as WebSphere JPA itself ( as I know
> it's
> >> > enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1 also.
> >> >
> >> > Anyway, problem still exists. What is most strange is that all
> >> > additional queries do not include field cur_code :
> >> >
> >> > executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name,
> t0.acc_seq,
> >> > t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
> >> >
> >> > openJPA somehow decides that there's no need in querying cur_code, but
> >> > it should query acc_name and some other fields. This logic does not
> >> have
> >> > explicit comprehension, since both fields are declared and used same
> >> way
> >> > in Account object.
> >> >
> >> > Best regards,
> >> > Mikhail V. Ostryanin
> >> > Sr.Developer/Analyst
> >> > UBS, Moscow
> >> > Tel: +7 495 648 22 14
> >> > Mikhail.Ostryanin@UBS.com
> >> >
> >> > -----Original Message-----
> >> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
> >> > Sent: Thursday, July 16, 2009 5:20 PM
> >> > To: users@openjpa.apache.org
> >> > Subject: Re: openJPA generates select per row - impossible to use for
> >> > simple select statements
> >> >
> >> > Hi Mikhail,
> >> > Your log file is showing at least one difference from my environment.
> >> > It
> >> > looks like you are (accidentally) using the subclassing support for
> >> > enhancement per this log statement:
> >> >
> >> > [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31
> MainPersistence
> >> > INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for
> >> > "[class
> >> > com.ubs.n3.persistence.ReportBond, class
> >> com.ubs.n3.persistence.Account,
> >> > class com.ubs.n3.persistence.N3Property]". This means that your
> >> > application
> >> > will be less efficient and will consume more memory than it would if
> >> you
> >> > ran
> >> > the OpenJPA enhancer. Additionally, lazy loading will not be available
> >> > for
> >> > one-to-one and many-to-one persistent attributes in types using field
> >> > access; they will be loaded eagerly instead.
> >> >
> >> > I thought I had asked about what type of enhancement processing you
> >> were
> >> > using, but maybe that was a different forum posting... You can find
> >> out
> >> > more about OpenJPA's enhancement processing here [1]. In a nutshell,
> >> > the
> >> > subclassing support is not meant for production use. It's meant for
> >> > some
> >> > simple, out of the box examples just to get people started. Real
> usage
> >> > of
> >> > OpenJPA would use one of the enhancement processes.
> >> >
> >> > What's interesting is that you mention that you are using OpenJPA
> >> within
> >> > WebSphere. The WebSphere packaged version of OpenJPA turns off this
> >> > subclassing support. If your applicaiton's processing should take you
> >> > into
> >> > the subclassing support, an error message should be logged to let you
> >> > know
> >> > of this condition. But, maybe you are just using OpenJPA as a shared
> >> > library or an applicaiton library. In that case, the default,
> >> > last-ditch
> >> > attempt at enhancement is the subclassing support.
> >> >
> >> > I'm also not prepared to say that this is definitely your problem.
> I'm
> >> > waiting for my development environment to boot up, so I will try it
> out
> >> > shortly. But, anytime that I see subclassing with an error condition,
> >> > it's
> >> > been a common culprit. I just wanted to get this bit of information
> >> out
> >> > to
> >> > you so that maybe we can try out variations at the same time.
> >> >
> >> > Good luck,
> >> > Kevin
> >> >
> >> >
> >> >
> >> > [1]
> >> >
> >>
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
> >> > l
> >> >
> >> > On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com>
> wrote:
> >> >
> >> > >
> >> > > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
> >> > >
> >> > > Hi All,
> >> > >
> >> > > Thank you very much for paying attention to my problem. In spite of
> >> it
> >> > > works
> >> > > with Hibernate, I don't like the idea to use another JPA and have
> >> > pretty
> >> > > many additional libs on board. I would like to fix the issue with
> >> > OpenJPA
> >> > > and use it since it's embedded in WebSphere server, at least.
> >> > >
> >> > > The code is extremely simple and clear. Stateless bean just returns
> >> > > query.getResultList() to struts2 action , which puts it in request
> >> > object
> >> > > for displaytag grid. The whole time spends in query.getResultList()
> >> > method.
> >> > >
> >> > > I've tried once more to remove IFilterTO and Map from Account
> object,
> >> > but
> >> > > with no result.
> >> > >
> >> > > I put asterisks before and after query.getResultList(), switched on
> >> > > runtime
> >> > > trace, and attached result log. It's pretty detailed, with many
> >> > openjpa
> >> > > runtime parameters and actions, may be somebody will be able to
> >> > determine
> >> > > what is happening...
> >> > >
> >> > > Database is ORACLE10, detailed version is present in attached log
> >> file
> >> > -
> >> > > openJPA determined it correctly. Tables are created automatically by
> >> > > OpenJPA
> >> > > using the following property in persistence.xml :
> >> > >
> >> > > <properties>
> >> > >
> >> > > <property name="openjpa.jdbc.SynchronizeMappings"
> >> > > value="buildSchema"/>
> >> > >
> >> > > </properties>
> >> > >
> >> > >
> >> > >
> >> > > IFilterTO interface just has two methods , nothing special :
> >> > >
> >> > > public interface IFilterTO {
> >> > > void setValue( String key, String value );
> >> > > String getValue( String key );
> >> > > }
> >> > >
> >> > > Thank you all in advance for your help.
> >> > >
> >> > > Mikhail
> >> > >
> >> > >
> >> > > Craig L Russell wrote:
> >> > > >
> >> > > > Hi,
> >> > > >
> >> > > > Could I ask again what the code is doing, following the
> >> > > > query.getResultList() ?
> >> > > >
> >> > > > Where is the list of results being used? Are the results being
> >> > > > serialized or detached?
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Craig
> >> > > >
> >> > > > On Jul 15, 2009, at 12:19 AM, om wrote:
> >> > > >
> >> > > >>
> >> > > >> Hi All!
> >> > > >>
> >> > > >> I'm new in openJPA, and didn't manage to get over the problem
> with
> >> > > >> simple
> >> > > >> select statement for one object after a few days of
> investigation.
> >> > > >> Please
> >> > > >> help!
> >> > > >>
> >> > > >> For simple select from one object, OpenJPA ( same strategy for
> >> 1.0,
> >> > > >> 1.2.1,
> >> > > >> 2.0 ) fist generates right query to retrieve all rows and fields,
> >> > > >> and then
> >> > > >> start generating query per object by primary key.
> >> > > >>
> >> > > >> Code :
> >> > > >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM
> >> > Account
> >> > > >> AS a
> >> > > >> WHERE a.date = :date ");
> >> > > >> PersistenceProviderImpl impl = new
> PersistenceProviderImpl();
> >> > > >> OpenJPAEntityManagerFactory fac =
> >> > > >> impl.createEntityManagerFactory("MainPersistence",
> >> > > >> System.getProperties());
> >> > > >> OpenJPAEntityManager man = fac.createEntityManager();
> >> > > >>
> >> > > >> Query query = man.createQuery(queryBuf.toString());
> >> > > >> query.setParameter("date", reportDate);
> >> > > >> List res = query.getResultList();
> >> > > >>
> >> > > >>
> >> > > >> LOG TRACE
> >> > > >>
> >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> > > >> openjpa.Runtime -
> >> > > >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is
> cached
> >> > > >> as target
> >> > > >> query "null"
> >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> > > >> openjpa.Query -
> >> > > >> Executing query: [SELECT a FROM Account AS a WHERE a.date =
> :date]
> >> > > >> with
> >> > > >> parameters: {date=java.util.GregorianCalendar[]}
> >> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> > > >> openjpa.jdbc.SQL
> >> > > >> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956
> >> > > >> SELECT
> >> > > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask,
> t0.acc_name,
> >> > > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> >> > > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
> >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> >> > > >> openjpa.jdbc.SQL -
> >> > > >> <t 1495423266, conn 1329090360> [78 ms] spent
> >> > > >>
> >> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> >> > > >> openjpa.jdbc.SQL -
> >> > > >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958
> >> > SELECT
> >> > > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE
> >> > > >> t0.id = ?
> >> > > >> [params=(long) 328]
> >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> >> > > >> [WebContainer : 2]
> >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> >> > > >> [WebContainer : 2]
> >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> >> > prepstmnt
> >> > > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> >> > > >> ACCOUNT t0
> >> > > >> WHERE t0.id = ? [params=(long) 329]
> >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> >> > > >> [WebContainer : 2]
> >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> >> > > >> [WebContainer : 2]
> >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> >> > prepstmnt
> >> > > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> >> > > >> ACCOUNT t0
> >> > > >> WHERE t0.id = ? [params=(long) 330]
> >> > > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
> >> > > >> [WebContainer : 2]
> >> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> > > >> ......................................
> >> > > >>
> >> > > >>
> >> > > >> I need just list of detached objects to show it in grid. As it's
> >> > > >> seen from
> >> > > >> log trace above, first query is enough to return all necessary
> >> > > >> objects and
> >> > > >> fields.
> >> > > >> Why OpenJPA makes select per object after that? In this case
> >> simple
> >> > > >> code
> >> > > >> above works 37 seconds for retrieving 440 rows, since same jdbc
> >> > > >> select and
> >> > > >> wrap works 1.5 sec. I've tried different query hints and a few
> >> > openjpa
> >> > > >> versions, but with no result.
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> View this message in context:
> >> > > >>
> >> > >
> >> >
> >>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> >> > e-for-simple-select-statements-tp3261512p3261512.html<
> >>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html
> >> >
> >> > > >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >> > > >
> >> > > > Craig L Russell
> >> > > > Architect, Sun Java Enterprise System http://db.apache.org/jdo
> >> > > > 408 276-5638 mailto:Craig.Russell@sun.com
> >> > > > P.S. A good JDO? O, Gasp!
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > > --
> >> > > View this message in context:
> >> > >
> >> >
> >>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> >> > e-for-simple-select-statements-tp3261512p3267829.html<
> >>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html
> >> >
> >> > > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >> > >
> >> > Visit our website at http://www.ubs.com
> >> >
> >> > This message contains confidential information and is intended only
> >> > for the individual named. If you are not the named addressee you
> >> > should not disseminate, distribute or copy this e-mail. Please
> >> > notify the sender immediately by e-mail if you have received this
> >> > e-mail by mistake and delete this e-mail from your system.
> >> >
> >> > E-mails are not encrypted and cannot be guaranteed to be secure or
> >> > error-free as information could be intercepted, corrupted, lost,
> >> > destroyed, arrive late or incomplete, or contain viruses. The sender
> >> > therefore does not accept liability for any errors or omissions in the
> >> > contents of this message which arise as a result of e-mail
> >> transmission.
> >> > If verification is required please request a hard-copy version. This
> >> > message is provided for informational purposes and should not be
> >> > construed as a solicitation or offer to buy or sell any securities
> >> > or related financial instruments.
> >> >
> >> >
> >> > UBS reserves the right to retain all messages. Messages are protected
> >> > and accessed only in legally justified cases.
> >> >
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3273854.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by om <mi...@ubs.com>.
Hi Kevin, Ravi,
Thank you very much for paying close attention to my problem. The issue has
been found and fixed due to your last messages. openJPA stopped generating
additional requests when I eliminated Util.resetTime(date) from setDate()
method. Since I couldn't imagine that it might somehow affect generation
process, I left this invocation while trying to simplify Account object
earlier. So, when I substituted
this.date = Util.resetTime(date);
with
this.date = date;
in method
public void setDate(Calendar date)
it started working fine.
Could anybody please let me know if it's an openJPA known restriction (not
to use other methods in getters and setters), or a bug?
Kevin Sutter wrote:
>
> Doesn't seem to apply. I have also reproduced that error message with my
> testing, but I still haven't reproduced Mikhail's problem. Next option is
> to try Oracle...
>
> On Thu, Jul 16, 2009 at 11:49 AM, Ravi Palacherla <
> ravi.palacherla@oracle.com> wrote:
>
>> Hi Kevin,
>>
>> I see the following in the log:
>>
>> [7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93 MainPersistence
>> WARN [WebContainer : 0] openjpa.Enhance - [Possible violation of
>> subclassing contract detected while processing persistent field
>> com.ubs.n3.persistence.Account.date, declared in null. Are you sure you
>> are
>> obeying the OpenJPA requirements? Details: The setter for field date does
>> not obey OpenJPAs subclassing restrictions. Setters must assign the
>> passed-in parameter to a single field in the object.]
>>
>> Do you have any idea what it means ?
>> Could it be related to this issue ?
>>
>> Regards,
>> Ravi.
>>
>> -----Original Message-----
>> From: Kevin Sutter [mailto:kwsutter@gmail.com]
>> Sent: Thursday, July 16, 2009 7:46 AM
>> To: users@openjpa.apache.org
>> Subject: Re: openJPA generates select per row - impossible to use for
>> simple select statements
>>
>> :-) Totally agree that it doesn't make sense. I also noticed that the
>> cur_code field is not re-queried. Still investigating...
>>
>> On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
>> Mikhail.Ostryanin@ubs.com> wrote:
>>
>> >
>> > Hi!
>> >
>> > Thank you for response!
>> >
>> > You're right, this log file was produced by last openJPA 2.0
>> > implementation linked to the application. But I have the same problem
>> > (generating additional select statements by primary key) with OpenJPA
>> > embedded in WebSphere, as well as WebSphere JPA itself ( as I know it's
>> > enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1 also.
>> >
>> > Anyway, problem still exists. What is most strange is that all
>> > additional queries do not include field cur_code :
>> >
>> > executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name, t0.acc_seq,
>> > t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
>> >
>> > openJPA somehow decides that there's no need in querying cur_code, but
>> > it should query acc_name and some other fields. This logic does not
>> have
>> > explicit comprehension, since both fields are declared and used same
>> way
>> > in Account object.
>> >
>> > Best regards,
>> > Mikhail V. Ostryanin
>> > Sr.Developer/Analyst
>> > UBS, Moscow
>> > Tel: +7 495 648 22 14
>> > Mikhail.Ostryanin@UBS.com
>> >
>> > -----Original Message-----
>> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
>> > Sent: Thursday, July 16, 2009 5:20 PM
>> > To: users@openjpa.apache.org
>> > Subject: Re: openJPA generates select per row - impossible to use for
>> > simple select statements
>> >
>> > Hi Mikhail,
>> > Your log file is showing at least one difference from my environment.
>> > It
>> > looks like you are (accidentally) using the subclassing support for
>> > enhancement per this log statement:
>> >
>> > [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31 MainPersistence
>> > INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for
>> > "[class
>> > com.ubs.n3.persistence.ReportBond, class
>> com.ubs.n3.persistence.Account,
>> > class com.ubs.n3.persistence.N3Property]". This means that your
>> > application
>> > will be less efficient and will consume more memory than it would if
>> you
>> > ran
>> > the OpenJPA enhancer. Additionally, lazy loading will not be available
>> > for
>> > one-to-one and many-to-one persistent attributes in types using field
>> > access; they will be loaded eagerly instead.
>> >
>> > I thought I had asked about what type of enhancement processing you
>> were
>> > using, but maybe that was a different forum posting... You can find
>> out
>> > more about OpenJPA's enhancement processing here [1]. In a nutshell,
>> > the
>> > subclassing support is not meant for production use. It's meant for
>> > some
>> > simple, out of the box examples just to get people started. Real usage
>> > of
>> > OpenJPA would use one of the enhancement processes.
>> >
>> > What's interesting is that you mention that you are using OpenJPA
>> within
>> > WebSphere. The WebSphere packaged version of OpenJPA turns off this
>> > subclassing support. If your applicaiton's processing should take you
>> > into
>> > the subclassing support, an error message should be logged to let you
>> > know
>> > of this condition. But, maybe you are just using OpenJPA as a shared
>> > library or an applicaiton library. In that case, the default,
>> > last-ditch
>> > attempt at enhancement is the subclassing support.
>> >
>> > I'm also not prepared to say that this is definitely your problem. I'm
>> > waiting for my development environment to boot up, so I will try it out
>> > shortly. But, anytime that I see subclassing with an error condition,
>> > it's
>> > been a common culprit. I just wanted to get this bit of information
>> out
>> > to
>> > you so that maybe we can try out variations at the same time.
>> >
>> > Good luck,
>> > Kevin
>> >
>> >
>> >
>> > [1]
>> >
>> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
>> > l
>> >
>> > On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com> wrote:
>> >
>> > >
>> > > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
>> > >
>> > > Hi All,
>> > >
>> > > Thank you very much for paying attention to my problem. In spite of
>> it
>> > > works
>> > > with Hibernate, I don't like the idea to use another JPA and have
>> > pretty
>> > > many additional libs on board. I would like to fix the issue with
>> > OpenJPA
>> > > and use it since it's embedded in WebSphere server, at least.
>> > >
>> > > The code is extremely simple and clear. Stateless bean just returns
>> > > query.getResultList() to struts2 action , which puts it in request
>> > object
>> > > for displaytag grid. The whole time spends in query.getResultList()
>> > method.
>> > >
>> > > I've tried once more to remove IFilterTO and Map from Account object,
>> > but
>> > > with no result.
>> > >
>> > > I put asterisks before and after query.getResultList(), switched on
>> > > runtime
>> > > trace, and attached result log. It's pretty detailed, with many
>> > openjpa
>> > > runtime parameters and actions, may be somebody will be able to
>> > determine
>> > > what is happening...
>> > >
>> > > Database is ORACLE10, detailed version is present in attached log
>> file
>> > -
>> > > openJPA determined it correctly. Tables are created automatically by
>> > > OpenJPA
>> > > using the following property in persistence.xml :
>> > >
>> > > <properties>
>> > >
>> > > <property name="openjpa.jdbc.SynchronizeMappings"
>> > > value="buildSchema"/>
>> > >
>> > > </properties>
>> > >
>> > >
>> > >
>> > > IFilterTO interface just has two methods , nothing special :
>> > >
>> > > public interface IFilterTO {
>> > > void setValue( String key, String value );
>> > > String getValue( String key );
>> > > }
>> > >
>> > > Thank you all in advance for your help.
>> > >
>> > > Mikhail
>> > >
>> > >
>> > > Craig L Russell wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > Could I ask again what the code is doing, following the
>> > > > query.getResultList() ?
>> > > >
>> > > > Where is the list of results being used? Are the results being
>> > > > serialized or detached?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Craig
>> > > >
>> > > > On Jul 15, 2009, at 12:19 AM, om wrote:
>> > > >
>> > > >>
>> > > >> Hi All!
>> > > >>
>> > > >> I'm new in openJPA, and didn't manage to get over the problem with
>> > > >> simple
>> > > >> select statement for one object after a few days of investigation.
>> > > >> Please
>> > > >> help!
>> > > >>
>> > > >> For simple select from one object, OpenJPA ( same strategy for
>> 1.0,
>> > > >> 1.2.1,
>> > > >> 2.0 ) fist generates right query to retrieve all rows and fields,
>> > > >> and then
>> > > >> start generating query per object by primary key.
>> > > >>
>> > > >> Code :
>> > > >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM
>> > Account
>> > > >> AS a
>> > > >> WHERE a.date = :date ");
>> > > >> PersistenceProviderImpl impl = new PersistenceProviderImpl();
>> > > >> OpenJPAEntityManagerFactory fac =
>> > > >> impl.createEntityManagerFactory("MainPersistence",
>> > > >> System.getProperties());
>> > > >> OpenJPAEntityManager man = fac.createEntityManager();
>> > > >>
>> > > >> Query query = man.createQuery(queryBuf.toString());
>> > > >> query.setParameter("date", reportDate);
>> > > >> List res = query.getResultList();
>> > > >>
>> > > >>
>> > > >> LOG TRACE
>> > > >>
>> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> > > >> openjpa.Runtime -
>> > > >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached
>> > > >> as target
>> > > >> query "null"
>> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> > > >> openjpa.Query -
>> > > >> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date]
>> > > >> with
>> > > >> parameters: {date=java.util.GregorianCalendar[]}
>> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> > > >> openjpa.jdbc.SQL
>> > > >> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956
>> > > >> SELECT
>> > > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
>> > > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
>> > > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
>> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> > > >> openjpa.jdbc.SQL -
>> > > >> <t 1495423266, conn 1329090360> [78 ms] spent
>> > > >>
>> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> > > >> openjpa.jdbc.SQL -
>> > > >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958
>> > SELECT
>> > > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE
>> > > >> t0.id = ?
>> > > >> [params=(long) 328]
>> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>> > > >> [WebContainer : 2]
>> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>> > > >> [WebContainer : 2]
>> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
>> > prepstmnt
>> > > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
>> > > >> ACCOUNT t0
>> > > >> WHERE t0.id = ? [params=(long) 329]
>> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>> > > >> [WebContainer : 2]
>> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>> > > >> [WebContainer : 2]
>> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
>> > prepstmnt
>> > > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
>> > > >> ACCOUNT t0
>> > > >> WHERE t0.id = ? [params=(long) 330]
>> > > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
>> > > >> [WebContainer : 2]
>> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> > > >> ......................................
>> > > >>
>> > > >>
>> > > >> I need just list of detached objects to show it in grid. As it's
>> > > >> seen from
>> > > >> log trace above, first query is enough to return all necessary
>> > > >> objects and
>> > > >> fields.
>> > > >> Why OpenJPA makes select per object after that? In this case
>> simple
>> > > >> code
>> > > >> above works 37 seconds for retrieving 440 rows, since same jdbc
>> > > >> select and
>> > > >> wrap works 1.5 sec. I've tried different query hints and a few
>> > openjpa
>> > > >> versions, but with no result.
>> > > >>
>> > > >>
>> > > >> --
>> > > >> View this message in context:
>> > > >>
>> > >
>> >
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
>> > e-for-simple-select-statements-tp3261512p3261512.html<
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html
>> >
>> > > >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>> > > >
>> > > > Craig L Russell
>> > > > Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> > > > 408 276-5638 mailto:Craig.Russell@sun.com
>> > > > P.S. A good JDO? O, Gasp!
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > > --
>> > > View this message in context:
>> > >
>> >
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
>> > e-for-simple-select-statements-tp3261512p3267829.html<
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html
>> >
>> > > Sent from the OpenJPA Users mailing list archive at Nabble.com.
>> > >
>> > Visit our website at http://www.ubs.com
>> >
>> > This message contains confidential information and is intended only
>> > for the individual named. If you are not the named addressee you
>> > should not disseminate, distribute or copy this e-mail. Please
>> > notify the sender immediately by e-mail if you have received this
>> > e-mail by mistake and delete this e-mail from your system.
>> >
>> > E-mails are not encrypted and cannot be guaranteed to be secure or
>> > error-free as information could be intercepted, corrupted, lost,
>> > destroyed, arrive late or incomplete, or contain viruses. The sender
>> > therefore does not accept liability for any errors or omissions in the
>> > contents of this message which arise as a result of e-mail
>> transmission.
>> > If verification is required please request a hard-copy version. This
>> > message is provided for informational purposes and should not be
>> > construed as a solicitation or offer to buy or sell any securities
>> > or related financial instruments.
>> >
>> >
>> > UBS reserves the right to retain all messages. Messages are protected
>> > and accessed only in legally justified cases.
>> >
>>
>
>
--
View this message in context: http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3273854.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
Doesn't seem to apply. I have also reproduced that error message with my
testing, but I still haven't reproduced Mikhail's problem. Next option is
to try Oracle...
On Thu, Jul 16, 2009 at 11:49 AM, Ravi Palacherla <
ravi.palacherla@oracle.com> wrote:
> Hi Kevin,
>
> I see the following in the log:
>
> [7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93 MainPersistence
> WARN [WebContainer : 0] openjpa.Enhance - [Possible violation of
> subclassing contract detected while processing persistent field
> com.ubs.n3.persistence.Account.date, declared in null. Are you sure you are
> obeying the OpenJPA requirements? Details: The setter for field date does
> not obey OpenJPAs subclassing restrictions. Setters must assign the
> passed-in parameter to a single field in the object.]
>
> Do you have any idea what it means ?
> Could it be related to this issue ?
>
> Regards,
> Ravi.
>
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Thursday, July 16, 2009 7:46 AM
> To: users@openjpa.apache.org
> Subject: Re: openJPA generates select per row - impossible to use for
> simple select statements
>
> :-) Totally agree that it doesn't make sense. I also noticed that the
> cur_code field is not re-queried. Still investigating...
>
> On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
> Mikhail.Ostryanin@ubs.com> wrote:
>
> >
> > Hi!
> >
> > Thank you for response!
> >
> > You're right, this log file was produced by last openJPA 2.0
> > implementation linked to the application. But I have the same problem
> > (generating additional select statements by primary key) with OpenJPA
> > embedded in WebSphere, as well as WebSphere JPA itself ( as I know it's
> > enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1 also.
> >
> > Anyway, problem still exists. What is most strange is that all
> > additional queries do not include field cur_code :
> >
> > executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name, t0.acc_seq,
> > t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
> >
> > openJPA somehow decides that there's no need in querying cur_code, but
> > it should query acc_name and some other fields. This logic does not have
> > explicit comprehension, since both fields are declared and used same way
> > in Account object.
> >
> > Best regards,
> > Mikhail V. Ostryanin
> > Sr.Developer/Analyst
> > UBS, Moscow
> > Tel: +7 495 648 22 14
> > Mikhail.Ostryanin@UBS.com
> >
> > -----Original Message-----
> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
> > Sent: Thursday, July 16, 2009 5:20 PM
> > To: users@openjpa.apache.org
> > Subject: Re: openJPA generates select per row - impossible to use for
> > simple select statements
> >
> > Hi Mikhail,
> > Your log file is showing at least one difference from my environment.
> > It
> > looks like you are (accidentally) using the subclassing support for
> > enhancement per this log statement:
> >
> > [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31 MainPersistence
> > INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for
> > "[class
> > com.ubs.n3.persistence.ReportBond, class com.ubs.n3.persistence.Account,
> > class com.ubs.n3.persistence.N3Property]". This means that your
> > application
> > will be less efficient and will consume more memory than it would if you
> > ran
> > the OpenJPA enhancer. Additionally, lazy loading will not be available
> > for
> > one-to-one and many-to-one persistent attributes in types using field
> > access; they will be loaded eagerly instead.
> >
> > I thought I had asked about what type of enhancement processing you were
> > using, but maybe that was a different forum posting... You can find out
> > more about OpenJPA's enhancement processing here [1]. In a nutshell,
> > the
> > subclassing support is not meant for production use. It's meant for
> > some
> > simple, out of the box examples just to get people started. Real usage
> > of
> > OpenJPA would use one of the enhancement processes.
> >
> > What's interesting is that you mention that you are using OpenJPA within
> > WebSphere. The WebSphere packaged version of OpenJPA turns off this
> > subclassing support. If your applicaiton's processing should take you
> > into
> > the subclassing support, an error message should be logged to let you
> > know
> > of this condition. But, maybe you are just using OpenJPA as a shared
> > library or an applicaiton library. In that case, the default,
> > last-ditch
> > attempt at enhancement is the subclassing support.
> >
> > I'm also not prepared to say that this is definitely your problem. I'm
> > waiting for my development environment to boot up, so I will try it out
> > shortly. But, anytime that I see subclassing with an error condition,
> > it's
> > been a common culprit. I just wanted to get this bit of information out
> > to
> > you so that maybe we can try out variations at the same time.
> >
> > Good luck,
> > Kevin
> >
> >
> >
> > [1]
> > http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
> > l
> >
> > On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com> wrote:
> >
> > >
> > > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
> > >
> > > Hi All,
> > >
> > > Thank you very much for paying attention to my problem. In spite of it
> > > works
> > > with Hibernate, I don't like the idea to use another JPA and have
> > pretty
> > > many additional libs on board. I would like to fix the issue with
> > OpenJPA
> > > and use it since it's embedded in WebSphere server, at least.
> > >
> > > The code is extremely simple and clear. Stateless bean just returns
> > > query.getResultList() to struts2 action , which puts it in request
> > object
> > > for displaytag grid. The whole time spends in query.getResultList()
> > method.
> > >
> > > I've tried once more to remove IFilterTO and Map from Account object,
> > but
> > > with no result.
> > >
> > > I put asterisks before and after query.getResultList(), switched on
> > > runtime
> > > trace, and attached result log. It's pretty detailed, with many
> > openjpa
> > > runtime parameters and actions, may be somebody will be able to
> > determine
> > > what is happening...
> > >
> > > Database is ORACLE10, detailed version is present in attached log file
> > -
> > > openJPA determined it correctly. Tables are created automatically by
> > > OpenJPA
> > > using the following property in persistence.xml :
> > >
> > > <properties>
> > >
> > > <property name="openjpa.jdbc.SynchronizeMappings"
> > > value="buildSchema"/>
> > >
> > > </properties>
> > >
> > >
> > >
> > > IFilterTO interface just has two methods , nothing special :
> > >
> > > public interface IFilterTO {
> > > void setValue( String key, String value );
> > > String getValue( String key );
> > > }
> > >
> > > Thank you all in advance for your help.
> > >
> > > Mikhail
> > >
> > >
> > > Craig L Russell wrote:
> > > >
> > > > Hi,
> > > >
> > > > Could I ask again what the code is doing, following the
> > > > query.getResultList() ?
> > > >
> > > > Where is the list of results being used? Are the results being
> > > > serialized or detached?
> > > >
> > > > Thanks,
> > > >
> > > > Craig
> > > >
> > > > On Jul 15, 2009, at 12:19 AM, om wrote:
> > > >
> > > >>
> > > >> Hi All!
> > > >>
> > > >> I'm new in openJPA, and didn't manage to get over the problem with
> > > >> simple
> > > >> select statement for one object after a few days of investigation.
> > > >> Please
> > > >> help!
> > > >>
> > > >> For simple select from one object, OpenJPA ( same strategy for 1.0,
> > > >> 1.2.1,
> > > >> 2.0 ) fist generates right query to retrieve all rows and fields,
> > > >> and then
> > > >> start generating query per object by primary key.
> > > >>
> > > >> Code :
> > > >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM
> > Account
> > > >> AS a
> > > >> WHERE a.date = :date ");
> > > >> PersistenceProviderImpl impl = new PersistenceProviderImpl();
> > > >> OpenJPAEntityManagerFactory fac =
> > > >> impl.createEntityManagerFactory("MainPersistence",
> > > >> System.getProperties());
> > > >> OpenJPAEntityManager man = fac.createEntityManager();
> > > >>
> > > >> Query query = man.createQuery(queryBuf.toString());
> > > >> query.setParameter("date", reportDate);
> > > >> List res = query.getResultList();
> > > >>
> > > >>
> > > >> LOG TRACE
> > > >>
> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > > >> openjpa.Runtime -
> > > >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached
> > > >> as target
> > > >> query "null"
> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > > >> openjpa.Query -
> > > >> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date]
> > > >> with
> > > >> parameters: {date=java.util.GregorianCalendar[]}
> > > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > > >> openjpa.jdbc.SQL
> > > >> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956
> > > >> SELECT
> > > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
> > > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> > > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> > > >> openjpa.jdbc.SQL -
> > > >> <t 1495423266, conn 1329090360> [78 ms] spent
> > > >>
> > > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> > > >> openjpa.jdbc.SQL -
> > > >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958
> > SELECT
> > > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE
> > > >> t0.id = ?
> > > >> [params=(long) 328]
> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> > > >> [WebContainer : 2]
> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> > > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> > > >> [WebContainer : 2]
> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> > prepstmnt
> > > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> > > >> ACCOUNT t0
> > > >> WHERE t0.id = ? [params=(long) 329]
> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> > > >> [WebContainer : 2]
> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> > > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> > > >> [WebContainer : 2]
> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> > prepstmnt
> > > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> > > >> ACCOUNT t0
> > > >> WHERE t0.id = ? [params=(long) 330]
> > > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
> > > >> [WebContainer : 2]
> > > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> > > >> ......................................
> > > >>
> > > >>
> > > >> I need just list of detached objects to show it in grid. As it's
> > > >> seen from
> > > >> log trace above, first query is enough to return all necessary
> > > >> objects and
> > > >> fields.
> > > >> Why OpenJPA makes select per object after that? In this case simple
> > > >> code
> > > >> above works 37 seconds for retrieving 440 rows, since same jdbc
> > > >> select and
> > > >> wrap works 1.5 sec. I've tried different query hints and a few
> > openjpa
> > > >> versions, but with no result.
> > > >>
> > > >>
> > > >> --
> > > >> View this message in context:
> > > >>
> > >
> > http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> > e-for-simple-select-statements-tp3261512p3261512.html<
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html
> >
> > > >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> > > >
> > > > Craig L Russell
> > > > Architect, Sun Java Enterprise System http://db.apache.org/jdo
> > > > 408 276-5638 mailto:Craig.Russell@sun.com
> > > > P.S. A good JDO? O, Gasp!
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > View this message in context:
> > >
> > http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> > e-for-simple-select-statements-tp3261512p3267829.html<
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html
> >
> > > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> > >
> > Visit our website at http://www.ubs.com
> >
> > This message contains confidential information and is intended only
> > for the individual named. If you are not the named addressee you
> > should not disseminate, distribute or copy this e-mail. Please
> > notify the sender immediately by e-mail if you have received this
> > e-mail by mistake and delete this e-mail from your system.
> >
> > E-mails are not encrypted and cannot be guaranteed to be secure or
> > error-free as information could be intercepted, corrupted, lost,
> > destroyed, arrive late or incomplete, or contain viruses. The sender
> > therefore does not accept liability for any errors or omissions in the
> > contents of this message which arise as a result of e-mail transmission.
> > If verification is required please request a hard-copy version. This
> > message is provided for informational purposes and should not be
> > construed as a solicitation or offer to buy or sell any securities
> > or related financial instruments.
> >
> >
> > UBS reserves the right to retain all messages. Messages are protected
> > and accessed only in legally justified cases.
> >
>
RE: openJPA generates select per row - impossible to use for simple
select statements
Posted by Ravi Palacherla <ra...@oracle.com>.
Hi Kevin,
I see the following in the log:
[7/16/09 12:53:53:026 MSD] 0000001d SystemErr R 93 MainPersistence WARN [WebContainer : 0] openjpa.Enhance - [Possible violation of subclassing contract detected while processing persistent field com.ubs.n3.persistence.Account.date, declared in null. Are you sure you are obeying the OpenJPA requirements? Details: The setter for field date does not obey OpenJPAs subclassing restrictions. Setters must assign the passed-in parameter to a single field in the object.]
Do you have any idea what it means ?
Could it be related to this issue ?
Regards,
Ravi.
-----Original Message-----
From: Kevin Sutter [mailto:kwsutter@gmail.com]
Sent: Thursday, July 16, 2009 7:46 AM
To: users@openjpa.apache.org
Subject: Re: openJPA generates select per row - impossible to use for simple select statements
:-) Totally agree that it doesn't make sense. I also noticed that the
cur_code field is not re-queried. Still investigating...
On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
Mikhail.Ostryanin@ubs.com> wrote:
>
> Hi!
>
> Thank you for response!
>
> You're right, this log file was produced by last openJPA 2.0
> implementation linked to the application. But I have the same problem
> (generating additional select statements by primary key) with OpenJPA
> embedded in WebSphere, as well as WebSphere JPA itself ( as I know it's
> enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1 also.
>
> Anyway, problem still exists. What is most strange is that all
> additional queries do not include field cur_code :
>
> executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name, t0.acc_seq,
> t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
>
> openJPA somehow decides that there's no need in querying cur_code, but
> it should query acc_name and some other fields. This logic does not have
> explicit comprehension, since both fields are declared and used same way
> in Account object.
>
> Best regards,
> Mikhail V. Ostryanin
> Sr.Developer/Analyst
> UBS, Moscow
> Tel: +7 495 648 22 14
> Mikhail.Ostryanin@UBS.com
>
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Thursday, July 16, 2009 5:20 PM
> To: users@openjpa.apache.org
> Subject: Re: openJPA generates select per row - impossible to use for
> simple select statements
>
> Hi Mikhail,
> Your log file is showing at least one difference from my environment.
> It
> looks like you are (accidentally) using the subclassing support for
> enhancement per this log statement:
>
> [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31 MainPersistence
> INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for
> "[class
> com.ubs.n3.persistence.ReportBond, class com.ubs.n3.persistence.Account,
> class com.ubs.n3.persistence.N3Property]". This means that your
> application
> will be less efficient and will consume more memory than it would if you
> ran
> the OpenJPA enhancer. Additionally, lazy loading will not be available
> for
> one-to-one and many-to-one persistent attributes in types using field
> access; they will be loaded eagerly instead.
>
> I thought I had asked about what type of enhancement processing you were
> using, but maybe that was a different forum posting... You can find out
> more about OpenJPA's enhancement processing here [1]. In a nutshell,
> the
> subclassing support is not meant for production use. It's meant for
> some
> simple, out of the box examples just to get people started. Real usage
> of
> OpenJPA would use one of the enhancement processes.
>
> What's interesting is that you mention that you are using OpenJPA within
> WebSphere. The WebSphere packaged version of OpenJPA turns off this
> subclassing support. If your applicaiton's processing should take you
> into
> the subclassing support, an error message should be logged to let you
> know
> of this condition. But, maybe you are just using OpenJPA as a shared
> library or an applicaiton library. In that case, the default,
> last-ditch
> attempt at enhancement is the subclassing support.
>
> I'm also not prepared to say that this is definitely your problem. I'm
> waiting for my development environment to boot up, so I will try it out
> shortly. But, anytime that I see subclassing with an error condition,
> it's
> been a common culprit. I just wanted to get this bit of information out
> to
> you so that maybe we can try out variations at the same time.
>
> Good luck,
> Kevin
>
>
>
> [1]
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
> l
>
> On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com> wrote:
>
> >
> > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
> >
> > Hi All,
> >
> > Thank you very much for paying attention to my problem. In spite of it
> > works
> > with Hibernate, I don't like the idea to use another JPA and have
> pretty
> > many additional libs on board. I would like to fix the issue with
> OpenJPA
> > and use it since it's embedded in WebSphere server, at least.
> >
> > The code is extremely simple and clear. Stateless bean just returns
> > query.getResultList() to struts2 action , which puts it in request
> object
> > for displaytag grid. The whole time spends in query.getResultList()
> method.
> >
> > I've tried once more to remove IFilterTO and Map from Account object,
> but
> > with no result.
> >
> > I put asterisks before and after query.getResultList(), switched on
> > runtime
> > trace, and attached result log. It's pretty detailed, with many
> openjpa
> > runtime parameters and actions, may be somebody will be able to
> determine
> > what is happening...
> >
> > Database is ORACLE10, detailed version is present in attached log file
> -
> > openJPA determined it correctly. Tables are created automatically by
> > OpenJPA
> > using the following property in persistence.xml :
> >
> > <properties>
> >
> > <property name="openjpa.jdbc.SynchronizeMappings"
> > value="buildSchema"/>
> >
> > </properties>
> >
> >
> >
> > IFilterTO interface just has two methods , nothing special :
> >
> > public interface IFilterTO {
> > void setValue( String key, String value );
> > String getValue( String key );
> > }
> >
> > Thank you all in advance for your help.
> >
> > Mikhail
> >
> >
> > Craig L Russell wrote:
> > >
> > > Hi,
> > >
> > > Could I ask again what the code is doing, following the
> > > query.getResultList() ?
> > >
> > > Where is the list of results being used? Are the results being
> > > serialized or detached?
> > >
> > > Thanks,
> > >
> > > Craig
> > >
> > > On Jul 15, 2009, at 12:19 AM, om wrote:
> > >
> > >>
> > >> Hi All!
> > >>
> > >> I'm new in openJPA, and didn't manage to get over the problem with
> > >> simple
> > >> select statement for one object after a few days of investigation.
> > >> Please
> > >> help!
> > >>
> > >> For simple select from one object, OpenJPA ( same strategy for 1.0,
> > >> 1.2.1,
> > >> 2.0 ) fist generates right query to retrieve all rows and fields,
> > >> and then
> > >> start generating query per object by primary key.
> > >>
> > >> Code :
> > >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM
> Account
> > >> AS a
> > >> WHERE a.date = :date ");
> > >> PersistenceProviderImpl impl = new PersistenceProviderImpl();
> > >> OpenJPAEntityManagerFactory fac =
> > >> impl.createEntityManagerFactory("MainPersistence",
> > >> System.getProperties());
> > >> OpenJPAEntityManager man = fac.createEntityManager();
> > >>
> > >> Query query = man.createQuery(queryBuf.toString());
> > >> query.setParameter("date", reportDate);
> > >> List res = query.getResultList();
> > >>
> > >>
> > >> LOG TRACE
> > >>
> > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > >> openjpa.Runtime -
> > >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached
> > >> as target
> > >> query "null"
> > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > >> openjpa.Query -
> > >> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date]
> > >> with
> > >> parameters: {date=java.util.GregorianCalendar[]}
> > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > >> openjpa.jdbc.SQL
> > >> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956
> > >> SELECT
> > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
> > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
> > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> > >> openjpa.jdbc.SQL -
> > >> <t 1495423266, conn 1329090360> [78 ms] spent
> > >>
> > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> > >> openjpa.jdbc.SQL -
> > >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958
> SELECT
> > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE
> > >> t0.id = ?
> > >> [params=(long) 328]
> > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> > >> [WebContainer : 2]
> > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> > >> [WebContainer : 2]
> > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> prepstmnt
> > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> > >> ACCOUNT t0
> > >> WHERE t0.id = ? [params=(long) 329]
> > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> > >> [WebContainer : 2]
> > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> > >> [WebContainer : 2]
> > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> prepstmnt
> > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> > >> ACCOUNT t0
> > >> WHERE t0.id = ? [params=(long) 330]
> > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
> > >> [WebContainer : 2]
> > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> > >> ......................................
> > >>
> > >>
> > >> I need just list of detached objects to show it in grid. As it's
> > >> seen from
> > >> log trace above, first query is enough to return all necessary
> > >> objects and
> > >> fields.
> > >> Why OpenJPA makes select per object after that? In this case simple
> > >> code
> > >> above works 37 seconds for retrieving 440 rows, since same jdbc
> > >> select and
> > >> wrap works 1.5 sec. I've tried different query hints and a few
> openjpa
> > >> versions, but with no result.
> > >>
> > >>
> > >> --
> > >> View this message in context:
> > >>
> >
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> e-for-simple-select-statements-tp3261512p3261512.html<http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html>
> > >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> > >
> > > Craig L Russell
> > > Architect, Sun Java Enterprise System http://db.apache.org/jdo
> > > 408 276-5638 mailto:Craig.Russell@sun.com
> > > P.S. A good JDO? O, Gasp!
> > >
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> e-for-simple-select-statements-tp3261512p3267829.html<http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html>
> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
> Visit our website at http://www.ubs.com
>
> This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>
> E-mails are not encrypted and cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender
> therefore does not accept liability for any errors or omissions in the
> contents of this message which arise as a result of e-mail transmission.
> If verification is required please request a hard-copy version. This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities
> or related financial instruments.
>
>
> UBS reserves the right to retain all messages. Messages are protected
> and accessed only in legally justified cases.
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
:-) Totally agree that it doesn't make sense. I also noticed that the
cur_code field is not re-queried. Still investigating...
On Thu, Jul 16, 2009 at 8:42 AM, Ostryanin, Mikhail <
Mikhail.Ostryanin@ubs.com> wrote:
>
> Hi!
>
> Thank you for response!
>
> You're right, this log file was produced by last openJPA 2.0
> implementation linked to the application. But I have the same problem
> (generating additional select statements by primary key) with OpenJPA
> embedded in WebSphere, as well as WebSphere JPA itself ( as I know it's
> enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1 also.
>
> Anyway, problem still exists. What is most strange is that all
> additional queries do not include field cur_code :
>
> executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name, t0.acc_seq,
> t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
>
> openJPA somehow decides that there's no need in querying cur_code, but
> it should query acc_name and some other fields. This logic does not have
> explicit comprehension, since both fields are declared and used same way
> in Account object.
>
> Best regards,
> Mikhail V. Ostryanin
> Sr.Developer/Analyst
> UBS, Moscow
> Tel: +7 495 648 22 14
> Mikhail.Ostryanin@UBS.com
>
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Thursday, July 16, 2009 5:20 PM
> To: users@openjpa.apache.org
> Subject: Re: openJPA generates select per row - impossible to use for
> simple select statements
>
> Hi Mikhail,
> Your log file is showing at least one difference from my environment.
> It
> looks like you are (accidentally) using the subclassing support for
> enhancement per this log statement:
>
> [7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31 MainPersistence
> INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for
> "[class
> com.ubs.n3.persistence.ReportBond, class com.ubs.n3.persistence.Account,
> class com.ubs.n3.persistence.N3Property]". This means that your
> application
> will be less efficient and will consume more memory than it would if you
> ran
> the OpenJPA enhancer. Additionally, lazy loading will not be available
> for
> one-to-one and many-to-one persistent attributes in types using field
> access; they will be loaded eagerly instead.
>
> I thought I had asked about what type of enhancement processing you were
> using, but maybe that was a different forum posting... You can find out
> more about OpenJPA's enhancement processing here [1]. In a nutshell,
> the
> subclassing support is not meant for production use. It's meant for
> some
> simple, out of the box examples just to get people started. Real usage
> of
> OpenJPA would use one of the enhancement processes.
>
> What's interesting is that you mention that you are using OpenJPA within
> WebSphere. The WebSphere packaged version of OpenJPA turns off this
> subclassing support. If your applicaiton's processing should take you
> into
> the subclassing support, an error message should be logged to let you
> know
> of this condition. But, maybe you are just using OpenJPA as a shared
> library or an applicaiton library. In that case, the default,
> last-ditch
> attempt at enhancement is the subclassing support.
>
> I'm also not prepared to say that this is definitely your problem. I'm
> waiting for my development environment to boot up, so I will try it out
> shortly. But, anytime that I see subclassing with an error condition,
> it's
> been a common culprit. I just wanted to get this bit of information out
> to
> you so that maybe we can try out variations at the same time.
>
> Good luck,
> Kevin
>
>
>
> [1]
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
> l
>
> On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com> wrote:
>
> >
> > http://n2.nabble.com/file/n3267829/dump.rar dump.rar
> >
> > Hi All,
> >
> > Thank you very much for paying attention to my problem. In spite of it
> > works
> > with Hibernate, I don't like the idea to use another JPA and have
> pretty
> > many additional libs on board. I would like to fix the issue with
> OpenJPA
> > and use it since it's embedded in WebSphere server, at least.
> >
> > The code is extremely simple and clear. Stateless bean just returns
> > query.getResultList() to struts2 action , which puts it in request
> object
> > for displaytag grid. The whole time spends in query.getResultList()
> method.
> >
> > I've tried once more to remove IFilterTO and Map from Account object,
> but
> > with no result.
> >
> > I put asterisks before and after query.getResultList(), switched on
> > runtime
> > trace, and attached result log. It's pretty detailed, with many
> openjpa
> > runtime parameters and actions, may be somebody will be able to
> determine
> > what is happening...
> >
> > Database is ORACLE10, detailed version is present in attached log file
> -
> > openJPA determined it correctly. Tables are created automatically by
> > OpenJPA
> > using the following property in persistence.xml :
> >
> > <properties>
> >
> > <property name="openjpa.jdbc.SynchronizeMappings"
> > value="buildSchema"/>
> >
> > </properties>
> >
> >
> >
> > IFilterTO interface just has two methods , nothing special :
> >
> > public interface IFilterTO {
> > void setValue( String key, String value );
> > String getValue( String key );
> > }
> >
> > Thank you all in advance for your help.
> >
> > Mikhail
> >
> >
> > Craig L Russell wrote:
> > >
> > > Hi,
> > >
> > > Could I ask again what the code is doing, following the
> > > query.getResultList() ?
> > >
> > > Where is the list of results being used? Are the results being
> > > serialized or detached?
> > >
> > > Thanks,
> > >
> > > Craig
> > >
> > > On Jul 15, 2009, at 12:19 AM, om wrote:
> > >
> > >>
> > >> Hi All!
> > >>
> > >> I'm new in openJPA, and didn't manage to get over the problem with
> > >> simple
> > >> select statement for one object after a few days of investigation.
> > >> Please
> > >> help!
> > >>
> > >> For simple select from one object, OpenJPA ( same strategy for 1.0,
> > >> 1.2.1,
> > >> 2.0 ) fist generates right query to retrieve all rows and fields,
> > >> and then
> > >> start generating query per object by primary key.
> > >>
> > >> Code :
> > >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM
> Account
> > >> AS a
> > >> WHERE a.date = :date ");
> > >> PersistenceProviderImpl impl = new PersistenceProviderImpl();
> > >> OpenJPAEntityManagerFactory fac =
> > >> impl.createEntityManagerFactory("MainPersistence",
> > >> System.getProperties());
> > >> OpenJPAEntityManager man = fac.createEntityManager();
> > >>
> > >> Query query = man.createQuery(queryBuf.toString());
> > >> query.setParameter("date", reportDate);
> > >> List res = query.getResultList();
> > >>
> > >>
> > >> LOG TRACE
> > >>
> > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > >> openjpa.Runtime -
> > >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached
> > >> as target
> > >> query "null"
> > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > >> openjpa.Query -
> > >> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date]
> > >> with
> > >> parameters: {date=java.util.GregorianCalendar[]}
> > >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> > >> openjpa.jdbc.SQL
> > >> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956
> > >> SELECT
> > >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
> > >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> > >> [params=(Timestamp) 2009-07-03 00:00:00.0]
> > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> > >> openjpa.jdbc.SQL -
> > >> <t 1495423266, conn 1329090360> [78 ms] spent
> > >>
> > >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> > >> openjpa.jdbc.SQL -
> > >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958
> SELECT
> > >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE
> > >> t0.id = ?
> > >> [params=(long) 328]
> > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> > >> [WebContainer : 2]
> > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> > >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> > >> [WebContainer : 2]
> > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> prepstmnt
> > >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> > >> ACCOUNT t0
> > >> WHERE t0.id = ? [params=(long) 329]
> > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> > >> [WebContainer : 2]
> > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> > >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> > >> [WebContainer : 2]
> > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
> prepstmnt
> > >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> > >> ACCOUNT t0
> > >> WHERE t0.id = ? [params=(long) 330]
> > >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
> > >> [WebContainer : 2]
> > >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> > >> ......................................
> > >>
> > >>
> > >> I need just list of detached objects to show it in grid. As it's
> > >> seen from
> > >> log trace above, first query is enough to return all necessary
> > >> objects and
> > >> fields.
> > >> Why OpenJPA makes select per object after that? In this case simple
> > >> code
> > >> above works 37 seconds for retrieving 440 rows, since same jdbc
> > >> select and
> > >> wrap works 1.5 sec. I've tried different query hints and a few
> openjpa
> > >> versions, but with no result.
> > >>
> > >>
> > >> --
> > >> View this message in context:
> > >>
> >
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> e-for-simple-select-statements-tp3261512p3261512.html<http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3261512.html>
> > >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> > >
> > > Craig L Russell
> > > Architect, Sun Java Enterprise System http://db.apache.org/jdo
> > > 408 276-5638 mailto:Craig.Russell@sun.com
> > > P.S. A good JDO? O, Gasp!
> > >
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
> e-for-simple-select-statements-tp3261512p3267829.html<http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us%0Ae-for-simple-select-statements-tp3261512p3267829.html>
> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
> Visit our website at http://www.ubs.com
>
> This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>
> E-mails are not encrypted and cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender
> therefore does not accept liability for any errors or omissions in the
> contents of this message which arise as a result of e-mail transmission.
> If verification is required please request a hard-copy version. This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities
> or related financial instruments.
>
>
> UBS reserves the right to retain all messages. Messages are protected
> and accessed only in legally justified cases.
>
RE: openJPA generates select per row - impossible to use for simple select statements
Posted by "Ostryanin, Mikhail" <Mi...@ubs.com>.
Hi!
Thank you for response!
You're right, this log file was produced by last openJPA 2.0
implementation linked to the application. But I have the same problem
(generating additional select statements by primary key) with OpenJPA
embedded in WebSphere, as well as WebSphere JPA itself ( as I know it's
enhanced openJpa 1.0.2, if I'm right ), and with openJPA 1.2.1 also.
Anyway, problem still exists. What is most strange is that all
additional queries do not include field cur_code :
executing prepstmnt 1693607154 SELECT t0.mask, t0.acc_name, t0.acc_seq,
t0.value FROM ACCOUNT t0 WHERE t0.id = ? [params=(long) 328]
openJPA somehow decides that there's no need in querying cur_code, but
it should query acc_name and some other fields. This logic does not have
explicit comprehension, since both fields are declared and used same way
in Account object.
Best regards,
Mikhail V. Ostryanin
Sr.Developer/Analyst
UBS, Moscow
Tel: +7 495 648 22 14
Mikhail.Ostryanin@UBS.com
-----Original Message-----
From: Kevin Sutter [mailto:kwsutter@gmail.com]
Sent: Thursday, July 16, 2009 5:20 PM
To: users@openjpa.apache.org
Subject: Re: openJPA generates select per row - impossible to use for
simple select statements
Hi Mikhail,
Your log file is showing at least one difference from my environment.
It
looks like you are (accidentally) using the subclassing support for
enhancement per this log statement:
[7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31 MainPersistence
INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for
"[class
com.ubs.n3.persistence.ReportBond, class com.ubs.n3.persistence.Account,
class com.ubs.n3.persistence.N3Property]". This means that your
application
will be less efficient and will consume more memory than it would if you
ran
the OpenJPA enhancer. Additionally, lazy loading will not be available
for
one-to-one and many-to-one persistent attributes in types using field
access; they will be loaded eagerly instead.
I thought I had asked about what type of enhancement processing you were
using, but maybe that was a different forum posting... You can find out
more about OpenJPA's enhancement processing here [1]. In a nutshell,
the
subclassing support is not meant for production use. It's meant for
some
simple, out of the box examples just to get people started. Real usage
of
OpenJPA would use one of the enhancement processes.
What's interesting is that you mention that you are using OpenJPA within
WebSphere. The WebSphere packaged version of OpenJPA turns off this
subclassing support. If your applicaiton's processing should take you
into
the subclassing support, an error message should be logged to let you
know
of this condition. But, maybe you are just using OpenJPA as a shared
library or an applicaiton library. In that case, the default,
last-ditch
attempt at enhancement is the subclassing support.
I'm also not prepared to say that this is definitely your problem. I'm
waiting for my development environment to boot up, so I will try it out
shortly. But, anytime that I see subclassing with an error condition,
it's
been a common culprit. I just wanted to get this bit of information out
to
you so that maybe we can try out variations at the same time.
Good luck,
Kevin
[1]
http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.htm
l
On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com> wrote:
>
> http://n2.nabble.com/file/n3267829/dump.rar dump.rar
>
> Hi All,
>
> Thank you very much for paying attention to my problem. In spite of it
> works
> with Hibernate, I don't like the idea to use another JPA and have
pretty
> many additional libs on board. I would like to fix the issue with
OpenJPA
> and use it since it's embedded in WebSphere server, at least.
>
> The code is extremely simple and clear. Stateless bean just returns
> query.getResultList() to struts2 action , which puts it in request
object
> for displaytag grid. The whole time spends in query.getResultList()
method.
>
> I've tried once more to remove IFilterTO and Map from Account object,
but
> with no result.
>
> I put asterisks before and after query.getResultList(), switched on
> runtime
> trace, and attached result log. It's pretty detailed, with many
openjpa
> runtime parameters and actions, may be somebody will be able to
determine
> what is happening...
>
> Database is ORACLE10, detailed version is present in attached log file
-
> openJPA determined it correctly. Tables are created automatically by
> OpenJPA
> using the following property in persistence.xml :
>
> <properties>
>
> <property name="openjpa.jdbc.SynchronizeMappings"
> value="buildSchema"/>
>
> </properties>
>
>
>
> IFilterTO interface just has two methods , nothing special :
>
> public interface IFilterTO {
> void setValue( String key, String value );
> String getValue( String key );
> }
>
> Thank you all in advance for your help.
>
> Mikhail
>
>
> Craig L Russell wrote:
> >
> > Hi,
> >
> > Could I ask again what the code is doing, following the
> > query.getResultList() ?
> >
> > Where is the list of results being used? Are the results being
> > serialized or detached?
> >
> > Thanks,
> >
> > Craig
> >
> > On Jul 15, 2009, at 12:19 AM, om wrote:
> >
> >>
> >> Hi All!
> >>
> >> I'm new in openJPA, and didn't manage to get over the problem with
> >> simple
> >> select statement for one object after a few days of investigation.
> >> Please
> >> help!
> >>
> >> For simple select from one object, OpenJPA ( same strategy for 1.0,
> >> 1.2.1,
> >> 2.0 ) fist generates right query to retrieve all rows and fields,
> >> and then
> >> start generating query per object by primary key.
> >>
> >> Code :
> >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM
Account
> >> AS a
> >> WHERE a.date = :date ");
> >> PersistenceProviderImpl impl = new PersistenceProviderImpl();
> >> OpenJPAEntityManagerFactory fac =
> >> impl.createEntityManagerFactory("MainPersistence",
> >> System.getProperties());
> >> OpenJPAEntityManager man = fac.createEntityManager();
> >>
> >> Query query = man.createQuery(queryBuf.toString());
> >> query.setParameter("date", reportDate);
> >> List res = query.getResultList();
> >>
> >>
> >> LOG TRACE
> >>
> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> openjpa.Runtime -
> >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached
> >> as target
> >> query "null"
> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> openjpa.Query -
> >> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date]
> >> with
> >> parameters: {date=java.util.GregorianCalendar[]}
> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> openjpa.jdbc.SQL
> >> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956
> >> SELECT
> >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
> >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> >> [params=(Timestamp) 2009-07-03 00:00:00.0]
> >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> >> openjpa.jdbc.SQL -
> >> <t 1495423266, conn 1329090360> [78 ms] spent
> >>
> >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> >> openjpa.jdbc.SQL -
> >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958
SELECT
> >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE
> >> t0.id = ?
> >> [params=(long) 328]
> >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> >> [WebContainer : 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> >> [WebContainer : 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
prepstmnt
> >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> >> ACCOUNT t0
> >> WHERE t0.id = ? [params=(long) 329]
> >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> >> [WebContainer : 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> >> [WebContainer : 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing
prepstmnt
> >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> >> ACCOUNT t0
> >> WHERE t0.id = ? [params=(long) 330]
> >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
> >> [WebContainer : 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> ......................................
> >>
> >>
> >> I need just list of detached objects to show it in grid. As it's
> >> seen from
> >> log trace above, first query is enough to return all necessary
> >> objects and
> >> fields.
> >> Why OpenJPA makes select per object after that? In this case simple
> >> code
> >> above works 37 seconds for retrieving 440 rows, since same jdbc
> >> select and
> >> wrap works 1.5 sec. I've tried different query hints and a few
openjpa
> >> versions, but with no result.
> >>
> >>
> >> --
> >> View this message in context:
> >>
>
http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
e-for-simple-select-statements-tp3261512p3261512.html
> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
> > Craig L Russell
> > Architect, Sun Java Enterprise System http://db.apache.org/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
> >
> >
> >
>
> --
> View this message in context:
>
http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-us
e-for-simple-select-statements-tp3261512p3267829.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Mikhail,
Your log file is showing at least one difference from my environment. It
looks like you are (accidentally) using the subclassing support for
enhancement per this log statement:
[7/16/09 12:53:52:964 MSD] 0000001d SystemErr R 31 MainPersistence
INFO [WebContainer : 0] openjpa.Enhance - Creating subclass for "[class
com.ubs.n3.persistence.ReportBond, class com.ubs.n3.persistence.Account,
class com.ubs.n3.persistence.N3Property]". This means that your application
will be less efficient and will consume more memory than it would if you ran
the OpenJPA enhancer. Additionally, lazy loading will not be available for
one-to-one and many-to-one persistent attributes in types using field
access; they will be loaded eagerly instead.
I thought I had asked about what type of enhancement processing you were
using, but maybe that was a different forum posting... You can find out
more about OpenJPA's enhancement processing here [1]. In a nutshell, the
subclassing support is not meant for production use. It's meant for some
simple, out of the box examples just to get people started. Real usage of
OpenJPA would use one of the enhancement processes.
What's interesting is that you mention that you are using OpenJPA within
WebSphere. The WebSphere packaged version of OpenJPA turns off this
subclassing support. If your applicaiton's processing should take you into
the subclassing support, an error message should be logged to let you know
of this condition. But, maybe you are just using OpenJPA as a shared
library or an applicaiton library. In that case, the default, last-ditch
attempt at enhancement is the subclassing support.
I'm also not prepared to say that this is definitely your problem. I'm
waiting for my development environment to boot up, so I will try it out
shortly. But, anytime that I see subclassing with an error condition, it's
been a common culprit. I just wanted to get this bit of information out to
you so that maybe we can try out variations at the same time.
Good luck,
Kevin
[1]
http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
On Thu, Jul 16, 2009 at 4:41 AM, om <mi...@ubs.com> wrote:
>
> http://n2.nabble.com/file/n3267829/dump.rar dump.rar
>
> Hi All,
>
> Thank you very much for paying attention to my problem. In spite of it
> works
> with Hibernate, I don't like the idea to use another JPA and have pretty
> many additional libs on board. I would like to fix the issue with OpenJPA
> and use it since it's embedded in WebSphere server, at least.
>
> The code is extremely simple and clear. Stateless bean just returns
> query.getResultList() to struts2 action , which puts it in request object
> for displaytag grid. The whole time spends in query.getResultList() method.
>
> I’ve tried once more to remove IFilterTO and Map from Account object, but
> with no result.
>
> I put asterisks before and after query.getResultList(), switched on
> runtime
> trace, and attached result log. It’s pretty detailed, with many openjpa
> runtime parameters and actions, may be somebody will be able to determine
> what is happening…
>
> Database is ORACLE10, detailed version is present in attached log file –
> openJPA determined it correctly. Tables are created automatically by
> OpenJPA
> using the following property in persistence.xml :
>
> <properties>
>
> <property name="openjpa.jdbc.SynchronizeMappings"
> value="buildSchema"/>
>
> </properties>
>
>
>
> IFilterTO interface just has two methods , nothing special :
>
> public interface IFilterTO {
> void setValue( String key, String value );
> String getValue( String key );
> }
>
> Thank you all in advance for your help.
>
> Mikhail
>
>
> Craig L Russell wrote:
> >
> > Hi,
> >
> > Could I ask again what the code is doing, following the
> > query.getResultList() ?
> >
> > Where is the list of results being used? Are the results being
> > serialized or detached?
> >
> > Thanks,
> >
> > Craig
> >
> > On Jul 15, 2009, at 12:19 AM, om wrote:
> >
> >>
> >> Hi All!
> >>
> >> I’m new in openJPA, and didn’t manage to get over the problem with
> >> simple
> >> select statement for one object after a few days of investigation.
> >> Please
> >> help!
> >>
> >> For simple select from one object, OpenJPA ( same strategy for 1.0,
> >> 1.2.1,
> >> 2.0 ) fist generates right query to retrieve all rows and fields,
> >> and then
> >> start generating query per object by primary key.
> >>
> >> Code :
> >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM Account
> >> AS a
> >> WHERE a.date = :date ");
> >> PersistenceProviderImpl impl = new PersistenceProviderImpl();
> >> OpenJPAEntityManagerFactory fac =
> >> impl.createEntityManagerFactory("MainPersistence",
> >> System.getProperties());
> >> OpenJPAEntityManager man = fac.createEntityManager();
> >>
> >> Query query = man.createQuery(queryBuf.toString());
> >> query.setParameter("date", reportDate);
> >> List res = query.getResultList();
> >>
> >>
> >> LOG TRACE
> >>
> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> openjpa.Runtime -
> >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached
> >> as target
> >> query "null"
> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> openjpa.Query -
> >> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date]
> >> with
> >> parameters: {date=java.util.GregorianCalendar[]}
> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> openjpa.jdbc.SQL
> >> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956
> >> SELECT
> >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
> >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> >> [params=(Timestamp) 2009-07-03 00:00:00.0]
> >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> >> openjpa.jdbc.SQL -
> >> <t 1495423266, conn 1329090360> [78 ms] spent
> >>
> >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> >> openjpa.jdbc.SQL -
> >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958 SELECT
> >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE
> >> t0.id = ?
> >> [params=(long) 328]
> >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> >> [WebContainer : 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> >> [WebContainer : 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
> >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> >> ACCOUNT t0
> >> WHERE t0.id = ? [params=(long) 329]
> >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> >> [WebContainer : 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> >> [WebContainer : 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
> >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> >> ACCOUNT t0
> >> WHERE t0.id = ? [params=(long) 330]
> >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
> >> [WebContainer : 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> ………………………………..
> >>
> >>
> >> I need just list of detached objects to show it in grid. As it’s
> >> seen from
> >> log trace above, first query is enough to return all necessary
> >> objects and
> >> fields.
> >> Why OpenJPA makes select per object after that? In this case simple
> >> code
> >> above works 37 seconds for retrieving 440 rows, since same jdbc
> >> select and
> >> wrap works 1.5 sec. I’ve tried different query hints and a few openjpa
> >> versions, but with no result.
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3261512.html
> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
> > Craig L Russell
> > Architect, Sun Java Enterprise System http://db.apache.org/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
> >
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3267829.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by om <mi...@ubs.com>.
http://n2.nabble.com/file/n3267829/dump.rar dump.rar
Hi All,
Thank you very much for paying attention to my problem. In spite of it works
with Hibernate, I don't like the idea to use another JPA and have pretty
many additional libs on board. I would like to fix the issue with OpenJPA
and use it since it's embedded in WebSphere server, at least.
The code is extremely simple and clear. Stateless bean just returns
query.getResultList() to struts2 action , which puts it in request object
for displaytag grid. The whole time spends in query.getResultList() method.
I’ve tried once more to remove IFilterTO and Map from Account object, but
with no result.
I put asterisks before and after query.getResultList(), switched on runtime
trace, and attached result log. It’s pretty detailed, with many openjpa
runtime parameters and actions, may be somebody will be able to determine
what is happening…
Database is ORACLE10, detailed version is present in attached log file –
openJPA determined it correctly. Tables are created automatically by OpenJPA
using the following property in persistence.xml :
<properties>
<property name="openjpa.jdbc.SynchronizeMappings"
value="buildSchema"/>
</properties>
IFilterTO interface just has two methods , nothing special :
public interface IFilterTO {
void setValue( String key, String value );
String getValue( String key );
}
Thank you all in advance for your help.
Mikhail
Craig L Russell wrote:
>
> Hi,
>
> Could I ask again what the code is doing, following the
> query.getResultList() ?
>
> Where is the list of results being used? Are the results being
> serialized or detached?
>
> Thanks,
>
> Craig
>
> On Jul 15, 2009, at 12:19 AM, om wrote:
>
>>
>> Hi All!
>>
>> I’m new in openJPA, and didn’t manage to get over the problem with
>> simple
>> select statement for one object after a few days of investigation.
>> Please
>> help!
>>
>> For simple select from one object, OpenJPA ( same strategy for 1.0,
>> 1.2.1,
>> 2.0 ) fist generates right query to retrieve all rows and fields,
>> and then
>> start generating query per object by primary key.
>>
>> Code :
>> StringBuffer queryBuf = new StringBuffer("SELECT a FROM Account
>> AS a
>> WHERE a.date = :date ");
>> PersistenceProviderImpl impl = new PersistenceProviderImpl();
>> OpenJPAEntityManagerFactory fac =
>> impl.createEntityManagerFactory("MainPersistence",
>> System.getProperties());
>> OpenJPAEntityManager man = fac.createEntityManager();
>>
>> Query query = man.createQuery(queryBuf.toString());
>> query.setParameter("date", reportDate);
>> List res = query.getResultList();
>>
>>
>> LOG TRACE
>>
>> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> openjpa.Runtime -
>> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached
>> as target
>> query "null"
>> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> openjpa.Query -
>> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date]
>> with
>> parameters: {date=java.util.GregorianCalendar[]}
>> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> openjpa.jdbc.SQL
>> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956
>> SELECT
>> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
>> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
>> [params=(Timestamp) 2009-07-03 00:00:00.0]
>> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> openjpa.jdbc.SQL -
>> <t 1495423266, conn 1329090360> [78 ms] spent
>>
>> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> openjpa.jdbc.SQL -
>> <t 1495423266, conn 1329090360> executing prepstmnt 139855958 SELECT
>> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE
>> t0.id = ?
>> [params=(long) 328]
>> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>> [WebContainer : 2]
>> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>> [WebContainer : 2]
>> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
>> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
>> ACCOUNT t0
>> WHERE t0.id = ? [params=(long) 329]
>> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>> [WebContainer : 2]
>> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>> [WebContainer : 2]
>> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
>> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
>> ACCOUNT t0
>> WHERE t0.id = ? [params=(long) 330]
>> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
>> [WebContainer : 2]
>> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> ………………………………..
>>
>>
>> I need just list of detached objects to show it in grid. As it’s
>> seen from
>> log trace above, first query is enough to return all necessary
>> objects and
>> fields.
>> Why OpenJPA makes select per object after that? In this case simple
>> code
>> above works 37 seconds for retrieving 440 rows, since same jdbc
>> select and
>> wrap works 1.5 sec. I’ve tried different query hints and a few openjpa
>> versions, but with no result.
>>
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3261512.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
>
--
View this message in context: http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3267829.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi,
Could I ask again what the code is doing, following the
query.getResultList() ?
Where is the list of results being used? Are the results being
serialized or detached?
Thanks,
Craig
On Jul 15, 2009, at 12:19 AM, om wrote:
>
> Hi All!
>
> I’m new in openJPA, and didn’t manage to get over the problem with
> simple
> select statement for one object after a few days of investigation.
> Please
> help!
>
> For simple select from one object, OpenJPA ( same strategy for 1.0,
> 1.2.1,
> 2.0 ) fist generates right query to retrieve all rows and fields,
> and then
> start generating query per object by primary key.
>
> Code :
> StringBuffer queryBuf = new StringBuffer("SELECT a FROM Account
> AS a
> WHERE a.date = :date ");
> PersistenceProviderImpl impl = new PersistenceProviderImpl();
> OpenJPAEntityManagerFactory fac =
> impl.createEntityManagerFactory("MainPersistence",
> System.getProperties());
> OpenJPAEntityManager man = fac.createEntityManager();
>
> Query query = man.createQuery(queryBuf.toString());
> query.setParameter("date", reportDate);
> List res = query.getResultList();
>
>
> LOG TRACE
>
> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> openjpa.Runtime -
> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached
> as target
> query "null"
> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> openjpa.Query -
> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date]
> with
> parameters: {date=java.util.GregorianCalendar[]}
> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> openjpa.jdbc.SQL
> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956
> SELECT
> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> [params=(Timestamp) 2009-07-03 00:00:00.0]
> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> openjpa.jdbc.SQL -
> <t 1495423266, conn 1329090360> [78 ms] spent
>
> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> openjpa.jdbc.SQL -
> <t 1495423266, conn 1329090360> executing prepstmnt 139855958 SELECT
> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE
> t0.id = ?
> [params=(long) 328]
> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> [WebContainer : 2]
> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
> [WebContainer : 2]
> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> ACCOUNT t0
> WHERE t0.id = ? [params=(long) 329]
> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> [WebContainer : 2]
> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
> [WebContainer : 2]
> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> ACCOUNT t0
> WHERE t0.id = ? [params=(long) 330]
> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
> [WebContainer : 2]
> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> ………………………………..
>
>
> I need just list of detached objects to show it in grid. As it’s
> seen from
> log trace above, first query is enough to return all necessary
> objects and
> fields.
> Why OpenJPA makes select per object after that? In this case simple
> code
> above works 37 seconds for retrieving 440 rows, since same jdbc
> select and
> wrap works 1.5 sec. I’ve tried different query hints and a few openjpa
> versions, but with no result.
>
>
> --
> View this message in context: http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3261512.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by rpalache <ra...@oracle.com>.
May be dumb questions /Suggestions, but I have the following:
1) If you add System.out.println("*****") before and after "List res =
query.getResultList(); "
then all these SQL traces are shown between these "*****" ?
I think the answer for above is true. Please let me know if that is not
the case.
2) Also can you please try to remove map from the entity and see if it makes
any difference ?
Reason for this is because recently I have noticed that, in case
collections are part of entity the SQL generation is not efficient in some
scenarios. I opened a JIRA for this OPENJPA-1140.
This is related to modifying the collections and detaching the object. In
your case Map is transient and hence may not be related to the JIRA but just
curious to see if removing collections is making any difference.
3) I gave a simple testcase (unable to reproduce with it) in another post on
the same subject.
Can you please try to modify it and break it ?
Regards,
Ravi.
Kevin Sutter wrote:
>
> Of course, pull the Hibernate card... Now you have my attention! :-)
>
> I've been trying every which way to reproduce this problem with no luck.
> For some reason, OpenJPA is interpreting these Account entities as not
> being
> complete after the initial Select, and then proceeds to query each
> individual row to fill in the other values. There doesn't seem to be
> anything special with these fields that are supposedly incomplete - three
> Strings and a BigDecimal. At first I thought it might be due to the TABLE
> id generation type, but no luck. I tried your various field definitions,
> no
> luck. I tried querying for a specific Date like you did, no luck.
>
> Is there anything special in the IFilterTO interface?
>
> I'll continue to experiment, but if anybody has another ideas, I would be
> interested.
>
> Kevin
>
> On Wed, Jul 15, 2009 at 8:26 AM, om <mi...@ubs.com> wrote:
>
>>
>> Hi Kevin,
>> Below is the object. It's the full version, but when I tried to make it
>> as
>> simple as possible, the problem did not disappear.
>> Moreover, I've tried Hibernate JPA, and with it same code works
>> perfectly,
>> with no additional queries. But OPENJPA continues generating additional
>> queries per entity.
>>
>> Here is Hibernate usage I tried instead of OPENJPA :
>> HibernatePersistence per = new HibernatePersistence();
>> EntityManagerFactory fac =
>> per.createEntityManagerFactory("MainPersistence",
>> System.getProperties());
>> EntityManager man = fac.createEntityManager();
>>
>> Account object :
>>
>> public class Account implements Serializable, Comparable, IFilterTO {
>>
>> public static final String FIELD_NAME = "Account";
>> public static final String FIELD_MASK = "Mask";
>> public static final String FIELD_CURRENCY_CODE = "Currency Code";
>>
>> public static final String[] FILTER_FIELDS = new String[]{
>> FIELD_NAME, FIELD_MASK, FIELD_CURRENCY_CODE
>> };
>>
>> Map mapVals = new HashMap();
>>
>> Long id;
>> String name;
>> String seq;
>> String mask;
>> String curCode;
>> Calendar date;
>> BigDecimal val;
>> Integer version;
>> boolean clearAccountDataFlag;
>>
>> public Account() {
>> }
>>
>> public Account(String account, String seq, String mask, String curCode,
>> Calendar date, BigDecimal val, boolean
>> clearAccountDataFlag) {
>> setName(account);
>> setMask(mask);
>> setSeq(seq);
>> setDate(date);
>> setVal(val);
>> setClearAccountDataFlag(clearAccountDataFlag);
>> setCurCode(curCode);
>> }
>>
>> @Override
>> public boolean equals(Object o) {
>> if (this == o) return true;
>> if (!(o instanceof Account)) return false;
>>
>> Account account1 = (Account) o;
>>
>> if (!name.equals(account1.name)) return false;
>> if (!seq.equals(account1.seq)) return false;
>> if (!mask.equals(account1.mask)) return false;
>> if (!curCode.equals(account1.curCode)) return false;
>> if (!date.equals(account1.date)) return false;
>>
>> return true;
>> }
>>
>> @Override
>> public int hashCode() {
>> int result = name.hashCode();
>> result = 31 * result + seq.hashCode();
>> result = 31 * result + mask.hashCode();
>> result = 31 * result + curCode.hashCode();
>> result = 31 * result + date.hashCode();
>> return result;
>> }
>>
>> public int compareTo(Object o) {
>> if (this == o) return 0;
>> if (!(o instanceof Account)) return 0;
>>
>> Account account1 = (Account) o;
>>
>> if (!name.equals(account1.name)) return name.compareTo(account1.name
>> );
>> if (!seq.equals(account1.seq)) return seq.compareTo(account1.seq);
>> if (!mask.equals(account1.mask)) return
>> mask.compareTo(account1.mask);
>> if (!curCode.equals(account1.curCode)) return
>> curCode.compareTo(account1.curCode);
>> if (!date.equals(account1.date)) return
>> date.compareTo(account1.date);
>>
>> return 0;
>> }
>>
>>
>> @Transient
>> public Map getValues() {
>> return mapVals;
>> }
>>
>> public void setValues(Map mapVals) {
>> this.mapVals = mapVals;
>> }
>>
>>
>> @Id
>> @GeneratedValue(strategy=GenerationType.TABLE)
>> public Long getId() {
>> return id;
>> }
>>
>> public void setId(Long id) {
>> this.id = id;
>> }
>>
>> @Column(name="acc_name",length=100)
>> public String getName() {
>> return name;
>> }
>>
>> public void setName(String name) {
>> this.name = name;
>> setValue(FIELD_NAME, name);
>> }
>>
>> @Column(name="acc_seq",length=10)
>> public String getSeq() {
>> return seq;
>> }
>>
>> public void setSeq(String seq) {
>> this.seq = seq;
>> }
>>
>> @Column(name="mask",length=10)
>> public String getMask() {
>> return mask;
>> }
>>
>> public void setMask(String mask) {
>> this.mask = mask;
>> setValue(FIELD_MASK, mask);
>> }
>>
>> @Column(name="cur_code",length=10)
>> public String getCurCode() {
>> return curCode;
>> }
>>
>> public void setCurCode(String curCode) {
>> this.curCode = curCode;
>> setValue(FIELD_CURRENCY_CODE, curCode);
>> }
>>
>> @Column(name="acc_date")
>> public Calendar getDate() {
>> return date;
>> }
>>
>> public void setDate(Calendar date) {
>> this.date = Util.resetTime(date);
>> }
>>
>> @Column(name="value")
>> public BigDecimal getVal() {
>> return val;
>> }
>>
>> public void setVal(BigDecimal val) {
>> this.val = val;
>> }
>>
>> @Version
>> public Integer getVersion() {
>> return version;
>> }
>>
>> public void setVersion(Integer version) {
>> this.version = version;
>> }
>>
>> @Transient
>> public boolean isClearAccountDataFlag() {
>> return clearAccountDataFlag;
>> }
>>
>> public void setClearAccountDataFlag(boolean clearAccountDataFlag) {
>> this.clearAccountDataFlag = clearAccountDataFlag;
>> }
>>
>> public void setValue( String key, String value ) {
>> mapVals.put(key, value);
>> }
>>
>> @Transient
>> public String getValue( String key ) {
>> return (String)mapVals.get(key);
>> }
>>
>> }
>>
>>
>>
>>
>> Kevin Sutter wrote:
>> >
>> > Hi,
>> > How is the Account entity defined? From what you have provided, I
>> don't
>> > see
>> > a reason for the extra Select statements either. I'm just wondering if
>> > something in your Entity definition is (accidentally) triggering these
>> > extra
>> > interactions with the database.
>> >
>> > Thanks,
>> > Kevin
>> >
>> > On Wed, Jul 15, 2009 at 2:19 AM, om <mi...@ubs.com> wrote:
>> >
>> >>
>> >> Hi All!
>> >>
>> >> I’m new in openJPA, and didn’t manage to get over the problem with
>> simple
>> >> select statement for one object after a few days of investigation.
>> Please
>> >> help!
>> >>
>> >> For simple select from one object, OpenJPA ( same strategy for 1.0,
>> >> 1.2.1,
>> >> 2.0 ) fist generates right query to retrieve all rows and fields, and
>> >> then
>> >> start generating query per object by primary key.
>> >>
>> >> Code :
>> >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM Account
>> AS
>> a
>> >> WHERE a.date = :date ");
>> >> PersistenceProviderImpl impl = new PersistenceProviderImpl();
>> >> OpenJPAEntityManagerFactory fac =
>> >> impl.createEntityManagerFactory("MainPersistence",
>> >> System.getProperties());
>> >> OpenJPAEntityManager man = fac.createEntityManager();
>> >>
>> >> Query query = man.createQuery(queryBuf.toString());
>> >> query.setParameter("date", reportDate);
>> >> List res = query.getResultList();
>> >>
>> >>
>> >> LOG TRACE
>> >>
>> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> >> openjpa.Runtime
>> >> -
>> >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached as
>> >> target
>> >> query "null"
>> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> openjpa.Query
>> -
>> >> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date]
>> with
>> >> parameters: {date=java.util.GregorianCalendar[]}
>> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> >> openjpa.jdbc.SQL
>> >> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956
>> SELECT
>> >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
>> >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
>> >> [params=(Timestamp) 2009-07-03 00:00:00.0]
>> >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> >> openjpa.jdbc.SQL
>> >> -
>> >> <t 1495423266, conn 1329090360> [78 ms] spent
>> >>
>> >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> >> openjpa.jdbc.SQL
>> >> -
>> >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958 SELECT
>> >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE
>> t0.id=
>> >> ?
>> >> [params=(long) 328]
>> >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>> [WebContainer
>> :
>> >> 2]
>> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE
>> [WebContainer
>> :
>> >> 2]
>> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
>> >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
>> ACCOUNT
>> >> t0
>> >> WHERE t0.id = ? [params=(long) 329]
>> >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>> [WebContainer
>> :
>> >> 2]
>> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE
>> [WebContainer
>> :
>> >> 2]
>> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
>> >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
>> ACCOUNT
>> >> t0
>> >> WHERE t0.id = ? [params=(long) 330]
>> >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE
>> [WebContainer
>> :
>> >> 2]
>> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> >> ………………………………..
>> >>
>> >>
>> >> I need just list of detached objects to show it in grid. As it’s seen
>> >> from
>> >> log trace above, first query is enough to return all necessary objects
>> >> and
>> >> fields.
>> >> Why OpenJPA makes select per object after that? In this case simple
>> code
>> >> above works 37 seconds for retrieving 440 rows, since same jdbc select
>> >> and
>> >> wrap works 1.5 sec. I’ve tried different query hints and a few openjpa
>> >> versions, but with no result.
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3261512.html
>> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3263178.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>
>
--
View this message in context: http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3264957.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
I've been trying with just Derby and letting OpenJPA create the necessary
tables. What database are you using? And, how are the tables getting
created, or did they pre-exist? If the pre-existed, then could you provide
the ddl for the database and tables?
Any other configuration properties that are in use?
Thanks,
Kevin
On Wed, Jul 15, 2009 at 11:27 AM, Kevin Sutter <kw...@gmail.com> wrote:
> Of course, pull the Hibernate card... Now you have my attention! :-)
>
> I've been trying every which way to reproduce this problem with no luck.
> For some reason, OpenJPA is interpreting these Account entities as not being
> complete after the initial Select, and then proceeds to query each
> individual row to fill in the other values. There doesn't seem to be
> anything special with these fields that are supposedly incomplete - three
> Strings and a BigDecimal. At first I thought it might be due to the TABLE
> id generation type, but no luck. I tried your various field definitions, no
> luck. I tried querying for a specific Date like you did, no luck.
>
> Is there anything special in the IFilterTO interface?
>
> I'll continue to experiment, but if anybody has another ideas, I would be
> interested.
>
> Kevin
>
>
> On Wed, Jul 15, 2009 at 8:26 AM, om <mi...@ubs.com> wrote:
>
>>
>> Hi Kevin,
>> Below is the object. It's the full version, but when I tried to make it as
>> simple as possible, the problem did not disappear.
>> Moreover, I've tried Hibernate JPA, and with it same code works perfectly,
>> with no additional queries. But OPENJPA continues generating additional
>> queries per entity.
>>
>> Here is Hibernate usage I tried instead of OPENJPA :
>> HibernatePersistence per = new HibernatePersistence();
>> EntityManagerFactory fac =
>> per.createEntityManagerFactory("MainPersistence", System.getProperties());
>> EntityManager man = fac.createEntityManager();
>>
>> Account object :
>>
>> public class Account implements Serializable, Comparable, IFilterTO {
>>
>> public static final String FIELD_NAME = "Account";
>> public static final String FIELD_MASK = "Mask";
>> public static final String FIELD_CURRENCY_CODE = "Currency Code";
>>
>> public static final String[] FILTER_FIELDS = new String[]{
>> FIELD_NAME, FIELD_MASK, FIELD_CURRENCY_CODE
>> };
>>
>> Map mapVals = new HashMap();
>>
>> Long id;
>> String name;
>> String seq;
>> String mask;
>> String curCode;
>> Calendar date;
>> BigDecimal val;
>> Integer version;
>> boolean clearAccountDataFlag;
>>
>> public Account() {
>> }
>>
>> public Account(String account, String seq, String mask, String curCode,
>> Calendar date, BigDecimal val, boolean
>> clearAccountDataFlag) {
>> setName(account);
>> setMask(mask);
>> setSeq(seq);
>> setDate(date);
>> setVal(val);
>> setClearAccountDataFlag(clearAccountDataFlag);
>> setCurCode(curCode);
>> }
>>
>> @Override
>> public boolean equals(Object o) {
>> if (this == o) return true;
>> if (!(o instanceof Account)) return false;
>>
>> Account account1 = (Account) o;
>>
>> if (!name.equals(account1.name)) return false;
>> if (!seq.equals(account1.seq)) return false;
>> if (!mask.equals(account1.mask)) return false;
>> if (!curCode.equals(account1.curCode)) return false;
>> if (!date.equals(account1.date)) return false;
>>
>> return true;
>> }
>>
>> @Override
>> public int hashCode() {
>> int result = name.hashCode();
>> result = 31 * result + seq.hashCode();
>> result = 31 * result + mask.hashCode();
>> result = 31 * result + curCode.hashCode();
>> result = 31 * result + date.hashCode();
>> return result;
>> }
>>
>> public int compareTo(Object o) {
>> if (this == o) return 0;
>> if (!(o instanceof Account)) return 0;
>>
>> Account account1 = (Account) o;
>>
>> if (!name.equals(account1.name)) return name.compareTo(account1.name
>> );
>> if (!seq.equals(account1.seq)) return seq.compareTo(account1.seq);
>> if (!mask.equals(account1.mask)) return
>> mask.compareTo(account1.mask);
>> if (!curCode.equals(account1.curCode)) return
>> curCode.compareTo(account1.curCode);
>> if (!date.equals(account1.date)) return
>> date.compareTo(account1.date);
>>
>> return 0;
>> }
>>
>>
>> @Transient
>> public Map getValues() {
>> return mapVals;
>> }
>>
>> public void setValues(Map mapVals) {
>> this.mapVals = mapVals;
>> }
>>
>>
>> @Id
>> @GeneratedValue(strategy=GenerationType.TABLE)
>> public Long getId() {
>> return id;
>> }
>>
>> public void setId(Long id) {
>> this.id = id;
>> }
>>
>> @Column(name="acc_name",length=100)
>> public String getName() {
>> return name;
>> }
>>
>> public void setName(String name) {
>> this.name = name;
>> setValue(FIELD_NAME, name);
>> }
>>
>> @Column(name="acc_seq",length=10)
>> public String getSeq() {
>> return seq;
>> }
>>
>> public void setSeq(String seq) {
>> this.seq = seq;
>> }
>>
>> @Column(name="mask",length=10)
>> public String getMask() {
>> return mask;
>> }
>>
>> public void setMask(String mask) {
>> this.mask = mask;
>> setValue(FIELD_MASK, mask);
>> }
>>
>> @Column(name="cur_code",length=10)
>> public String getCurCode() {
>> return curCode;
>> }
>>
>> public void setCurCode(String curCode) {
>> this.curCode = curCode;
>> setValue(FIELD_CURRENCY_CODE, curCode);
>> }
>>
>> @Column(name="acc_date")
>> public Calendar getDate() {
>> return date;
>> }
>>
>> public void setDate(Calendar date) {
>> this.date = Util.resetTime(date);
>> }
>>
>> @Column(name="value")
>> public BigDecimal getVal() {
>> return val;
>> }
>>
>> public void setVal(BigDecimal val) {
>> this.val = val;
>> }
>>
>> @Version
>> public Integer getVersion() {
>> return version;
>> }
>>
>> public void setVersion(Integer version) {
>> this.version = version;
>> }
>>
>> @Transient
>> public boolean isClearAccountDataFlag() {
>> return clearAccountDataFlag;
>> }
>>
>> public void setClearAccountDataFlag(boolean clearAccountDataFlag) {
>> this.clearAccountDataFlag = clearAccountDataFlag;
>> }
>>
>> public void setValue( String key, String value ) {
>> mapVals.put(key, value);
>> }
>>
>> @Transient
>> public String getValue( String key ) {
>> return (String)mapVals.get(key);
>> }
>>
>> }
>>
>>
>>
>>
>> Kevin Sutter wrote:
>> >
>> > Hi,
>> > How is the Account entity defined? From what you have provided, I don't
>> > see
>> > a reason for the extra Select statements either. I'm just wondering if
>> > something in your Entity definition is (accidentally) triggering these
>> > extra
>> > interactions with the database.
>> >
>> > Thanks,
>> > Kevin
>> >
>> > On Wed, Jul 15, 2009 at 2:19 AM, om <mi...@ubs.com> wrote:
>> >
>> >>
>> >> Hi All!
>> >>
>> >> I’m new in openJPA, and didn’t manage to get over the problem with
>> simple
>> >> select statement for one object after a few days of investigation.
>> Please
>> >> help!
>> >>
>> >> For simple select from one object, OpenJPA ( same strategy for 1.0,
>> >> 1.2.1,
>> >> 2.0 ) fist generates right query to retrieve all rows and fields, and
>> >> then
>> >> start generating query per object by primary key.
>> >>
>> >> Code :
>> >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM Account AS
>> a
>> >> WHERE a.date = :date ");
>> >> PersistenceProviderImpl impl = new PersistenceProviderImpl();
>> >> OpenJPAEntityManagerFactory fac =
>> >> impl.createEntityManagerFactory("MainPersistence",
>> >> System.getProperties());
>> >> OpenJPAEntityManager man = fac.createEntityManager();
>> >>
>> >> Query query = man.createQuery(queryBuf.toString());
>> >> query.setParameter("date", reportDate);
>> >> List res = query.getResultList();
>> >>
>> >>
>> >> LOG TRACE
>> >>
>> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> >> openjpa.Runtime
>> >> -
>> >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached as
>> >> target
>> >> query "null"
>> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE openjpa.Query
>> -
>> >> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date] with
>> >> parameters: {date=java.util.GregorianCalendar[]}
>> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> >> openjpa.jdbc.SQL
>> >> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956 SELECT
>> >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
>> >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
>> >> [params=(Timestamp) 2009-07-03 00:00:00.0]
>> >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> >> openjpa.jdbc.SQL
>> >> -
>> >> <t 1495423266, conn 1329090360> [78 ms] spent
>> >>
>> >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> >> openjpa.jdbc.SQL
>> >> -
>> >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958 SELECT
>> >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE t0.id=
>> >> ?
>> >> [params=(long) 328]
>> >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE [WebContainer
>> :
>> >> 2]
>> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE [WebContainer
>> :
>> >> 2]
>> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
>> >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
>> ACCOUNT
>> >> t0
>> >> WHERE t0.id = ? [params=(long) 329]
>> >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE [WebContainer
>> :
>> >> 2]
>> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE [WebContainer
>> :
>> >> 2]
>> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
>> >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
>> ACCOUNT
>> >> t0
>> >> WHERE t0.id = ? [params=(long) 330]
>> >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE [WebContainer
>> :
>> >> 2]
>> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> >> ………………………………..
>> >>
>> >>
>> >> I need just list of detached objects to show it in grid. As it’s seen
>> >> from
>> >> log trace above, first query is enough to return all necessary objects
>> >> and
>> >> fields.
>> >> Why OpenJPA makes select per object after that? In this case simple
>> code
>> >> above works 37 seconds for retrieving 440 rows, since same jdbc select
>> >> and
>> >> wrap works 1.5 sec. I’ve tried different query hints and a few openjpa
>> >> versions, but with no result.
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3261512.html
>> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3263178.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
Of course, pull the Hibernate card... Now you have my attention! :-)
I've been trying every which way to reproduce this problem with no luck.
For some reason, OpenJPA is interpreting these Account entities as not being
complete after the initial Select, and then proceeds to query each
individual row to fill in the other values. There doesn't seem to be
anything special with these fields that are supposedly incomplete - three
Strings and a BigDecimal. At first I thought it might be due to the TABLE
id generation type, but no luck. I tried your various field definitions, no
luck. I tried querying for a specific Date like you did, no luck.
Is there anything special in the IFilterTO interface?
I'll continue to experiment, but if anybody has another ideas, I would be
interested.
Kevin
On Wed, Jul 15, 2009 at 8:26 AM, om <mi...@ubs.com> wrote:
>
> Hi Kevin,
> Below is the object. It's the full version, but when I tried to make it as
> simple as possible, the problem did not disappear.
> Moreover, I've tried Hibernate JPA, and with it same code works perfectly,
> with no additional queries. But OPENJPA continues generating additional
> queries per entity.
>
> Here is Hibernate usage I tried instead of OPENJPA :
> HibernatePersistence per = new HibernatePersistence();
> EntityManagerFactory fac =
> per.createEntityManagerFactory("MainPersistence", System.getProperties());
> EntityManager man = fac.createEntityManager();
>
> Account object :
>
> public class Account implements Serializable, Comparable, IFilterTO {
>
> public static final String FIELD_NAME = "Account";
> public static final String FIELD_MASK = "Mask";
> public static final String FIELD_CURRENCY_CODE = "Currency Code";
>
> public static final String[] FILTER_FIELDS = new String[]{
> FIELD_NAME, FIELD_MASK, FIELD_CURRENCY_CODE
> };
>
> Map mapVals = new HashMap();
>
> Long id;
> String name;
> String seq;
> String mask;
> String curCode;
> Calendar date;
> BigDecimal val;
> Integer version;
> boolean clearAccountDataFlag;
>
> public Account() {
> }
>
> public Account(String account, String seq, String mask, String curCode,
> Calendar date, BigDecimal val, boolean
> clearAccountDataFlag) {
> setName(account);
> setMask(mask);
> setSeq(seq);
> setDate(date);
> setVal(val);
> setClearAccountDataFlag(clearAccountDataFlag);
> setCurCode(curCode);
> }
>
> @Override
> public boolean equals(Object o) {
> if (this == o) return true;
> if (!(o instanceof Account)) return false;
>
> Account account1 = (Account) o;
>
> if (!name.equals(account1.name)) return false;
> if (!seq.equals(account1.seq)) return false;
> if (!mask.equals(account1.mask)) return false;
> if (!curCode.equals(account1.curCode)) return false;
> if (!date.equals(account1.date)) return false;
>
> return true;
> }
>
> @Override
> public int hashCode() {
> int result = name.hashCode();
> result = 31 * result + seq.hashCode();
> result = 31 * result + mask.hashCode();
> result = 31 * result + curCode.hashCode();
> result = 31 * result + date.hashCode();
> return result;
> }
>
> public int compareTo(Object o) {
> if (this == o) return 0;
> if (!(o instanceof Account)) return 0;
>
> Account account1 = (Account) o;
>
> if (!name.equals(account1.name)) return name.compareTo(account1.name
> );
> if (!seq.equals(account1.seq)) return seq.compareTo(account1.seq);
> if (!mask.equals(account1.mask)) return mask.compareTo(account1.mask);
> if (!curCode.equals(account1.curCode)) return
> curCode.compareTo(account1.curCode);
> if (!date.equals(account1.date)) return date.compareTo(account1.date);
>
> return 0;
> }
>
>
> @Transient
> public Map getValues() {
> return mapVals;
> }
>
> public void setValues(Map mapVals) {
> this.mapVals = mapVals;
> }
>
>
> @Id
> @GeneratedValue(strategy=GenerationType.TABLE)
> public Long getId() {
> return id;
> }
>
> public void setId(Long id) {
> this.id = id;
> }
>
> @Column(name="acc_name",length=100)
> public String getName() {
> return name;
> }
>
> public void setName(String name) {
> this.name = name;
> setValue(FIELD_NAME, name);
> }
>
> @Column(name="acc_seq",length=10)
> public String getSeq() {
> return seq;
> }
>
> public void setSeq(String seq) {
> this.seq = seq;
> }
>
> @Column(name="mask",length=10)
> public String getMask() {
> return mask;
> }
>
> public void setMask(String mask) {
> this.mask = mask;
> setValue(FIELD_MASK, mask);
> }
>
> @Column(name="cur_code",length=10)
> public String getCurCode() {
> return curCode;
> }
>
> public void setCurCode(String curCode) {
> this.curCode = curCode;
> setValue(FIELD_CURRENCY_CODE, curCode);
> }
>
> @Column(name="acc_date")
> public Calendar getDate() {
> return date;
> }
>
> public void setDate(Calendar date) {
> this.date = Util.resetTime(date);
> }
>
> @Column(name="value")
> public BigDecimal getVal() {
> return val;
> }
>
> public void setVal(BigDecimal val) {
> this.val = val;
> }
>
> @Version
> public Integer getVersion() {
> return version;
> }
>
> public void setVersion(Integer version) {
> this.version = version;
> }
>
> @Transient
> public boolean isClearAccountDataFlag() {
> return clearAccountDataFlag;
> }
>
> public void setClearAccountDataFlag(boolean clearAccountDataFlag) {
> this.clearAccountDataFlag = clearAccountDataFlag;
> }
>
> public void setValue( String key, String value ) {
> mapVals.put(key, value);
> }
>
> @Transient
> public String getValue( String key ) {
> return (String)mapVals.get(key);
> }
>
> }
>
>
>
>
> Kevin Sutter wrote:
> >
> > Hi,
> > How is the Account entity defined? From what you have provided, I don't
> > see
> > a reason for the extra Select statements either. I'm just wondering if
> > something in your Entity definition is (accidentally) triggering these
> > extra
> > interactions with the database.
> >
> > Thanks,
> > Kevin
> >
> > On Wed, Jul 15, 2009 at 2:19 AM, om <mi...@ubs.com> wrote:
> >
> >>
> >> Hi All!
> >>
> >> I’m new in openJPA, and didn’t manage to get over the problem with
> simple
> >> select statement for one object after a few days of investigation.
> Please
> >> help!
> >>
> >> For simple select from one object, OpenJPA ( same strategy for 1.0,
> >> 1.2.1,
> >> 2.0 ) fist generates right query to retrieve all rows and fields, and
> >> then
> >> start generating query per object by primary key.
> >>
> >> Code :
> >> StringBuffer queryBuf = new StringBuffer("SELECT a FROM Account AS
> a
> >> WHERE a.date = :date ");
> >> PersistenceProviderImpl impl = new PersistenceProviderImpl();
> >> OpenJPAEntityManagerFactory fac =
> >> impl.createEntityManagerFactory("MainPersistence",
> >> System.getProperties());
> >> OpenJPAEntityManager man = fac.createEntityManager();
> >>
> >> Query query = man.createQuery(queryBuf.toString());
> >> query.setParameter("date", reportDate);
> >> List res = query.getResultList();
> >>
> >>
> >> LOG TRACE
> >>
> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> openjpa.Runtime
> >> -
> >> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached as
> >> target
> >> query "null"
> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE openjpa.Query
> -
> >> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date] with
> >> parameters: {date=java.util.GregorianCalendar[]}
> >> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
> >> openjpa.jdbc.SQL
> >> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956 SELECT
> >> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
> >> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> >> [params=(Timestamp) 2009-07-03 00:00:00.0]
> >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> >> openjpa.jdbc.SQL
> >> -
> >> <t 1495423266, conn 1329090360> [78 ms] spent
> >>
> >> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
> >> openjpa.jdbc.SQL
> >> -
> >> <t 1495423266, conn 1329090360> executing prepstmnt 139855958 SELECT
> >> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE t0.id=
> >> ?
> >> [params=(long) 328]
> >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE [WebContainer
> :
> >> 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE [WebContainer
> :
> >> 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
> >> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT
> >> t0
> >> WHERE t0.id = ? [params=(long) 329]
> >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE [WebContainer
> :
> >> 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE [WebContainer
> :
> >> 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
> >> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM
> ACCOUNT
> >> t0
> >> WHERE t0.id = ? [params=(long) 330]
> >> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE [WebContainer
> :
> >> 2]
> >> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> >> ………………………………..
> >>
> >>
> >> I need just list of detached objects to show it in grid. As it’s seen
> >> from
> >> log trace above, first query is enough to return all necessary objects
> >> and
> >> fields.
> >> Why OpenJPA makes select per object after that? In this case simple code
> >> above works 37 seconds for retrieving 440 rows, since same jdbc select
> >> and
> >> wrap works 1.5 sec. I’ve tried different query hints and a few openjpa
> >> versions, but with no result.
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3261512.html
> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3263178.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by om <mi...@ubs.com>.
Hi Kevin,
Below is the object. It's the full version, but when I tried to make it as
simple as possible, the problem did not disappear.
Moreover, I've tried Hibernate JPA, and with it same code works perfectly,
with no additional queries. But OPENJPA continues generating additional
queries per entity.
Here is Hibernate usage I tried instead of OPENJPA :
HibernatePersistence per = new HibernatePersistence();
EntityManagerFactory fac =
per.createEntityManagerFactory("MainPersistence", System.getProperties());
EntityManager man = fac.createEntityManager();
Account object :
public class Account implements Serializable, Comparable, IFilterTO {
public static final String FIELD_NAME = "Account";
public static final String FIELD_MASK = "Mask";
public static final String FIELD_CURRENCY_CODE = "Currency Code";
public static final String[] FILTER_FIELDS = new String[]{
FIELD_NAME, FIELD_MASK, FIELD_CURRENCY_CODE
};
Map mapVals = new HashMap();
Long id;
String name;
String seq;
String mask;
String curCode;
Calendar date;
BigDecimal val;
Integer version;
boolean clearAccountDataFlag;
public Account() {
}
public Account(String account, String seq, String mask, String curCode,
Calendar date, BigDecimal val, boolean
clearAccountDataFlag) {
setName(account);
setMask(mask);
setSeq(seq);
setDate(date);
setVal(val);
setClearAccountDataFlag(clearAccountDataFlag);
setCurCode(curCode);
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (!(o instanceof Account)) return false;
Account account1 = (Account) o;
if (!name.equals(account1.name)) return false;
if (!seq.equals(account1.seq)) return false;
if (!mask.equals(account1.mask)) return false;
if (!curCode.equals(account1.curCode)) return false;
if (!date.equals(account1.date)) return false;
return true;
}
@Override
public int hashCode() {
int result = name.hashCode();
result = 31 * result + seq.hashCode();
result = 31 * result + mask.hashCode();
result = 31 * result + curCode.hashCode();
result = 31 * result + date.hashCode();
return result;
}
public int compareTo(Object o) {
if (this == o) return 0;
if (!(o instanceof Account)) return 0;
Account account1 = (Account) o;
if (!name.equals(account1.name)) return name.compareTo(account1.name);
if (!seq.equals(account1.seq)) return seq.compareTo(account1.seq);
if (!mask.equals(account1.mask)) return mask.compareTo(account1.mask);
if (!curCode.equals(account1.curCode)) return
curCode.compareTo(account1.curCode);
if (!date.equals(account1.date)) return date.compareTo(account1.date);
return 0;
}
@Transient
public Map getValues() {
return mapVals;
}
public void setValues(Map mapVals) {
this.mapVals = mapVals;
}
@Id
@GeneratedValue(strategy=GenerationType.TABLE)
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
@Column(name="acc_name",length=100)
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
setValue(FIELD_NAME, name);
}
@Column(name="acc_seq",length=10)
public String getSeq() {
return seq;
}
public void setSeq(String seq) {
this.seq = seq;
}
@Column(name="mask",length=10)
public String getMask() {
return mask;
}
public void setMask(String mask) {
this.mask = mask;
setValue(FIELD_MASK, mask);
}
@Column(name="cur_code",length=10)
public String getCurCode() {
return curCode;
}
public void setCurCode(String curCode) {
this.curCode = curCode;
setValue(FIELD_CURRENCY_CODE, curCode);
}
@Column(name="acc_date")
public Calendar getDate() {
return date;
}
public void setDate(Calendar date) {
this.date = Util.resetTime(date);
}
@Column(name="value")
public BigDecimal getVal() {
return val;
}
public void setVal(BigDecimal val) {
this.val = val;
}
@Version
public Integer getVersion() {
return version;
}
public void setVersion(Integer version) {
this.version = version;
}
@Transient
public boolean isClearAccountDataFlag() {
return clearAccountDataFlag;
}
public void setClearAccountDataFlag(boolean clearAccountDataFlag) {
this.clearAccountDataFlag = clearAccountDataFlag;
}
public void setValue( String key, String value ) {
mapVals.put(key, value);
}
@Transient
public String getValue( String key ) {
return (String)mapVals.get(key);
}
}
Kevin Sutter wrote:
>
> Hi,
> How is the Account entity defined? From what you have provided, I don't
> see
> a reason for the extra Select statements either. I'm just wondering if
> something in your Entity definition is (accidentally) triggering these
> extra
> interactions with the database.
>
> Thanks,
> Kevin
>
> On Wed, Jul 15, 2009 at 2:19 AM, om <mi...@ubs.com> wrote:
>
>>
>> Hi All!
>>
>> I’m new in openJPA, and didn’t manage to get over the problem with simple
>> select statement for one object after a few days of investigation. Please
>> help!
>>
>> For simple select from one object, OpenJPA ( same strategy for 1.0,
>> 1.2.1,
>> 2.0 ) fist generates right query to retrieve all rows and fields, and
>> then
>> start generating query per object by primary key.
>>
>> Code :
>> StringBuffer queryBuf = new StringBuffer("SELECT a FROM Account AS a
>> WHERE a.date = :date ");
>> PersistenceProviderImpl impl = new PersistenceProviderImpl();
>> OpenJPAEntityManagerFactory fac =
>> impl.createEntityManagerFactory("MainPersistence",
>> System.getProperties());
>> OpenJPAEntityManager man = fac.createEntityManager();
>>
>> Query query = man.createQuery(queryBuf.toString());
>> query.setParameter("date", reportDate);
>> List res = query.getResultList();
>>
>>
>> LOG TRACE
>>
>> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> openjpa.Runtime
>> -
>> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached as
>> target
>> query "null"
>> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE openjpa.Query -
>> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date] with
>> parameters: {date=java.util.GregorianCalendar[]}
>> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE
>> openjpa.jdbc.SQL
>> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956 SELECT
>> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
>> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
>> [params=(Timestamp) 2009-07-03 00:00:00.0]
>> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> openjpa.jdbc.SQL
>> -
>> <t 1495423266, conn 1329090360> [78 ms] spent
>>
>> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE
>> openjpa.jdbc.SQL
>> -
>> <t 1495423266, conn 1329090360> executing prepstmnt 139855958 SELECT
>> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE t0.id =
>> ?
>> [params=(long) 328]
>> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE [WebContainer :
>> 2]
>> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE [WebContainer :
>> 2]
>> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
>> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT
>> t0
>> WHERE t0.id = ? [params=(long) 329]
>> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE [WebContainer :
>> 2]
>> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE [WebContainer :
>> 2]
>> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
>> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT
>> t0
>> WHERE t0.id = ? [params=(long) 330]
>> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE [WebContainer :
>> 2]
>> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
>> ………………………………..
>>
>>
>> I need just list of detached objects to show it in grid. As it’s seen
>> from
>> log trace above, first query is enough to return all necessary objects
>> and
>> fields.
>> Why OpenJPA makes select per object after that? In this case simple code
>> above works 37 seconds for retrieving 440 rows, since same jdbc select
>> and
>> wrap works 1.5 sec. I’ve tried different query hints and a few openjpa
>> versions, but with no result.
>>
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3261512.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>
>
--
View this message in context: http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3263178.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: openJPA generates select per row - impossible to use for simple
select statements
Posted by Kevin Sutter <kw...@gmail.com>.
Hi,
How is the Account entity defined? From what you have provided, I don't see
a reason for the extra Select statements either. I'm just wondering if
something in your Entity definition is (accidentally) triggering these extra
interactions with the database.
Thanks,
Kevin
On Wed, Jul 15, 2009 at 2:19 AM, om <mi...@ubs.com> wrote:
>
> Hi All!
>
> I’m new in openJPA, and didn’t manage to get over the problem with simple
> select statement for one object after a few days of investigation. Please
> help!
>
> For simple select from one object, OpenJPA ( same strategy for 1.0, 1.2.1,
> 2.0 ) fist generates right query to retrieve all rows and fields, and then
> start generating query per object by primary key.
>
> Code :
> StringBuffer queryBuf = new StringBuffer("SELECT a FROM Account AS a
> WHERE a.date = :date ");
> PersistenceProviderImpl impl = new PersistenceProviderImpl();
> OpenJPAEntityManagerFactory fac =
> impl.createEntityManagerFactory("MainPersistence", System.getProperties());
> OpenJPAEntityManager man = fac.createEntityManager();
>
> Query query = man.createQuery(queryBuf.toString());
> query.setParameter("date", reportDate);
> List res = query.getResultList();
>
>
> LOG TRACE
>
> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE openjpa.Runtime
> -
> Query "SELECT a FROM Account AS a WHERE a.date = :date " is cached as
> target
> query "null"
> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE openjpa.Query -
> Executing query: [SELECT a FROM Account AS a WHERE a.date = :date] with
> parameters: {date=java.util.GregorianCalendar[]}
> [7/14/09 16:57:50:475 MSD] R 266 MainPersistence TRACE openjpa.jdbc.SQL
> - <t 1495423266, conn 1329090360> executing prepstmnt 1388597956 SELECT
> t0.id, t0.version, t0.cur_code, t0.acc_date, t0.mask, t0.acc_name,
> t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE (t0.acc_date = ?)
> [params=(Timestamp) 2009-07-03 00:00:00.0]
> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE openjpa.jdbc.SQL
> -
> <t 1495423266, conn 1329090360> [78 ms] spent
>
> [7/14/09 16:57:50:553 MSD] R 344 MainPersistence TRACE openjpa.jdbc.SQL
> -
> <t 1495423266, conn 1329090360> executing prepstmnt 139855958 SELECT
> t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0 WHERE t0.id = ?
> [params=(long) 328]
> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE [WebContainer :
> 2]
> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> [7/14/09 16:57:50:631 MSD] R 422 MainPersistence TRACE [WebContainer :
> 2]
> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
> 646850190 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT t0
> WHERE t0.id = ? [params=(long) 329]
> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE [WebContainer :
> 2]
> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> [7/14/09 16:57:50:709 MSD] R 500 MainPersistence TRACE [WebContainer :
> 2]
> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> executing prepstmnt
> 2146074602 SELECT t0.mask, t0.acc_name, t0.acc_seq, t0.value FROM ACCOUNT
> t0
> WHERE t0.id = ? [params=(long) 330]
> [7/14/09 16:57:50:787 MSD] R 578 MainPersistence TRACE [WebContainer :
> 2]
> openjpa.jdbc.SQL - <t 1495423266, conn 1329090360> [78 ms] spent
> ………………………………..
>
>
> I need just list of detached objects to show it in grid. As it’s seen from
> log trace above, first query is enough to return all necessary objects and
> fields.
> Why OpenJPA makes select per object after that? In this case simple code
> above works 37 seconds for retrieving 440 rows, since same jdbc select and
> wrap works 1.5 sec. I’ve tried different query hints and a few openjpa
> versions, but with no result.
>
>
> --
> View this message in context:
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-tp3261512p3261512.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>