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