openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject Re: openJPA generates select per row - impossible to use for simple select statements
Date Thu, 16 Jul 2009 17:08:27 GMT
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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message