openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From om <mikhail.ostrya...@ubs.com>
Subject Re: openJPA generates select per row - impossible to use for simple select statements
Date Mon, 20 Jul 2009 14:30:38 GMT

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
View raw message