JIRA Issue: https://issues.apache.org/jira/browse/OPENJPA-1188
On Tue, Jul 21, 2009 at 8:42 AM, Kevin Sutter <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 >>> >> <[email protected]>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 <[email protected]> >>> 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 < >>> >>> > > [email protected]> 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:[email protected]] >>> >>> > >> Sent: Thursday, July 16, 2009 7:46 AM >>> >>> > >> To: [email protected] >>> >>> > >> 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 < >>> >>> > >> [email protected]> 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 >>> >>> > >> > [email protected] >>> >>> > >> > >>> >>> > >> > -----Original Message----- >>> >>> > >> > From: Kevin Sutter [mailto:[email protected]] >>> >>> > >> > Sent: Thursday, July 16, 2009 5:20 PM >>> >>> > >> > To: [email protected] >>> >>> > >> > 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 < >>> [email protected]> >>> >>> > 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:[email protected] >>> >>> > >> > > > 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. >>> >> >> >
