Hi,
> > > when trying to connect to the CVS I constantly get "EOF from Server"
> I think it has to do with SF.net throttling the amount of pserver
> connections to the non-developer access CVS Server. I got it for a long
> time, and then I go through finally. It just takes time, keep trying.
Thi
Howdy,
Thanks - that was it for sure - the 7.3.2 PGSQL JDBC driver didn't handle it.
I upgraded to 7.3.4 and things worked fine.
Thanks again!
Gerry
Gavin King wrote:
I think it is a bug in the Postgres implementation of JDBC batch updates.
Gerry Duprey wrote:
Howdy,
I'm new to hibernate a
Ok, For some reason my Unit tests were passing when I wasn't using
hibernate to persist (even though they shouldn't have), I found my
problem (I wasn't initializing the internal Set before trying to use it
- doh!). So, this is now working, but I am experiencing another problem.
Here's my layout
Forget about the 500 transactions. The problem is
this: with 300-500 objects in the session cache, a
single transaction( with an single object inserted)
takes about one second.
It simply does *not* take a second to dirty check 500 objects, dude.
Nowhere even close. If you think you can prove that
First I have a source class like this.
public class Source
{
Transaction tx;
List pendingRemovedItems;
public void beginTransaction()
{
// here I use ThreadLocal pattern.
tx= ThreadState.getSession().beginTransaction();
}
Hi,
I have following situation:
Parent table:
ID - PK
NAME
MAIN_CHILD_ID - FK (has FK constraint) and can be null
Child table:
ID - PK
NAME
PARENT_ID - FK (has fk constraint) and not null
Mapping for this looks like:
jiesheng zhang wrote:
> Forget about the 500 transactions. The problem is
> this: with 300-500 objects in the session cache, a
> single transaction( with an single object inserted)
> takes about one second.
How long does a single transaction take in raw JDBC? I agree with
Gavin's implicit suggesti
Thats right. The newest version has fixed the problem. The direct link to
the file:
(Note: this file requires a JRE 1.4 (or better) jvm):
http://jdbc.postgresql.org/download/pg73jdbc3.jar
Les
Gavin King writes:
I think it is a bug in the Postgres implementation of JDBC batch updates.
So, let me get this straight:
you, *500 times*
(a) obtain a new JDBC connection
(b) start a transaction
(c) do some work
(d) commit the transaction and close the JDBC connection
and you are surprised that this is slow??
Why would you not do it all in one transaction? Starting and stopping
trans
--- Gavin King <[EMAIL PROTECTED]> wrote:
> So, let me get this straight:
>
> you, *500 times*
>
> (a) obtain a new JDBC connection
> (b) start a transaction
> (c) do some work
> (d) commit the transaction and close the JDBC
> connection
Not quite that.
I, *500 times*
(a') using the same connec
Dissable batch updates, there is no batch updates in server protocol, driver
just emulates this feature and it will not increase
performance on postgresql at this time.
> I think it is a bug in the Postgres implementation of JDBC batch updates.
>
> Gerry Duprey wrote:
>
> > Howdy,
> >
> > I'm n
11 matches
Mail list logo
