Could be a c3po or database driver bug. Are you using the latest
versions?
Martijn
On Fri, 2008-07-25 at 06:49 -0400, Chris Lewis wrote:
> Yep, that solved it.
>
> 0
>
> After that prepared statements work as normal. Doesn't the
> hibernate.c3p0.max_statements directive help improve performance
Hi,
I also use hibernate in dispatcher and some strange errors occurs, after
debugging whole day without any result, I commented out c3p0, and it works,
from there I proceeded, looks like disabling c3p0 is a good debugging method
when hibernate is giving out strange errors.
Chris Lewis-5 wrote:
Yep, that solved it.
0
After that prepared statements work as normal. Doesn't the
hibernate.c3p0.max_statements directive help improve performance though?
I mean, wouldn't it if it didn't fall over ... ;-)
Thanks Martijn, I'm glad I'm not crazy and will know to be wary of it in
the future.
chri
This posting also report similar problems and it was 'solved' by
disabling the statement cache.
https://jira.jboss.org/jira/browse/JBPORTAL-1287
Martijn
On Thu, 2008-07-24 at 22:57 -0700, Martijn Brinkers (List) wrote:
> Sounds to me something related to the PreparedStatement cache. Do you
> us
Sounds to me something related to the PreparedStatement cache. Do you
use c3po? If so did you specify hibernate.c3p0.max_statements?
Martijn
On Thu, 2008-07-24 at 23:26 -0400, Chris Lewis wrote:
> Ok, I've figured out what exactly is causing it and how to work around
> it. I can't say why, but
Ok, I've figured out what exactly is causing it and how to work around
it. I can't say why, but perhaps a resident hibernate guru will know (it
may even be a know issue or gotcha). First off, the quick fix. This
query (and variations like load(), get(), and using the criteria api)
cause the problem
Thiago,
You must not have read my explanation of just how erratic this is, so
here it is again:
Quick summary of the behavior with the following urls:
1) request /LStAug/?limg=1
works
2) request /LStAug/?limg=1 (again)
works
3) request /LStAug/?limg=2
breaks
4) request /LStAug/?limg=1
breaks,
Em Thu, 24 Jul 2008 18:14:32 -0300, Chris Lewis
<[EMAIL PROTECTED]> escreveu:
This is occurring in a development environment on a fresh and small app
with a schema with a total of 6 mapped entities, 7 tables, 3 records in
the abstract entity's table, one user (me), and all queries working
comp
QL statement, and
> > execute it manually.
> >
> > Also, can you change Listing to be non-abstract - even if you never use
> it?
> >
> >
> >
> >
> >> -Original Message-
> >> From: Chris Lewis [mailto:[EMAIL PROTECTED]
>
-
>> From: Chris Lewis [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, July 24, 2008 15:41
>> To: Tapestry users
>> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
>> Session
>>
>> I haven't looked at the source of hibernate (o
t; 2) request /LStAug/?limg=1
>> breaks
>>
>> 3) request /LStAug/?limg=2
>> breaks
>>
>> so strange.
>>
>>
>> Jonathan Barker wrote:
>>
>>> I'm not sure why it WORKED.
>>>
>>> Session.load will try to
Brian Lough wrote:
> Right on. So imagine Snoopy's fist shake to the sky after being
> perforated by the Red Baron (Hibernate). . . ;-)
>
> You're dealing with alot of code layers, and potentially a data issue
> here (one instance you are trying to query could be represented
> in the schema just
Chris Lewis-5 wrote:
>
> Do I need to do any manual hibernate cleanup? I thought this was handled
> by a background
> event but I'm at a bit of a loss...
>
Actually, Uber T5 folks, this raises a good question: when using an ORM
framework, are there specific gotcha's to be sensitive to when acc
Right on. So imagine Snoopy's fist shake to the sky after being
perforated by the Red Baron (Hibernate). . . ;-)
You're dealing with alot of code layers, and potentially a data issue
here (one instance you are trying to query could be represented
in the schema just differently enough to cause
5:41
> To: Tapestry users
> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
> Session
>
> I haven't looked at the source of hibernate (or read) to see what
> exactly goes on, but the erratic behavior of load() is precisely the
> same as this:
>
Padawn,
Per your suggestion I tried the get method with the exact same results:
Listing listing = (Listing)session.get(Listing.class,
Long.parseLong(sListingId));
I also changed the dispatcher so that it uses the
HibernateSessionManager to get the current session explicitly on each
request, to n
Since it's just my intuition speaking, I may be off-base, but...this sounds
like the beloved Hibernate Proxy and/or Cache issue, both of which
SnoopyDance all-over gray concurrency areas. Try substituting the query
code for a, literally, straight get(persistentClass, databaseId); call and
see if
t/html");
>>
>> String test = "" + listing.getTitle() +
>> "";
>> response.setContentLength(test.length());
>> response.getPrintWriter("text/html").append(test).flush();
>>
.flush();
> return true;
> }
>
> }
>
>
> Jonathan Barker wrote:
> > Post your query and load code.
> >
> >
> >> -Original Message-
> >> From: Chris Lewis [mailto:[EMAIL PROTECTED]
> >> Sent: Thursday, July
t; From: Chris Lewis [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, July 24, 2008 13:16
>> To: Tapestry users
>> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
>> Session
>>
>> It can't be a data issue. The records are persisted via hib
Post your query and load code.
> -Original Message-
> From: Chris Lewis [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 24, 2008 13:16
> To: Tapestry users
> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
> Session
>
> It can't be
It can't be a data issue. The records are persisted via hibernate and
work consistently as expected in pages. Like I said, I query the same
table to which the abstract class is mapped in my index page with no
problem at all. I also said that it works in the dispatcher for the
first entity I query,
It sounds more like a data issue, check your data in database carefully.
Yunhua
On Wed, Jul 23, 2008 at 11:18 PM, Chris Lewis <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have a dispatcher that uses a hibernate session. The dispatcher is
> auto bound and receives the session in the constructor. I'm
Hello,
I have a dispatcher that uses a hibernate session. The dispatcher is
auto bound and receives the session in the constructor. I'm using
tapestry-hibernate so that session instance is a proxy that gets the
real session for the current thread (right?). Now in testing my
dispatcher, I give it a
24 matches
Mail list logo
