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 Tue, 21 Jul 2009 13:42:30 GMT
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 <kwsutter@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 <mikhail.ostryanin@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 <kwsutter@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
>> >> <michael.d.dick@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 <mikhail.ostryanin@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.
>>
>
>

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