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