openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ostryanin, Mikhail" <Mikhail.Ostrya...@ubs.com>
Subject RE: openJPA generates select per row - impossible to use for simple select statements
Date Fri, 17 Jul 2009 06:34:07 GMT

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 <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.
> >
>
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.

Mime
View raw message