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