openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravi Palacherla <ravi.palache...@oracle.com>
Subject RE: openJPA generates select per row - impossible to use for simple select statements
Date Thu, 16 Jul 2009 16:49:57 GMT
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
View raw message