Re: [JDBC] downloading image blobs
hello.
the only time i remember seeing this error was after creating a new db from
a pg_dump...obviously it didn't copy the blobs, only the references to them.
so the db had a reference to something that didn't exist.
chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Matt Fair
Sent: Tuesday, September 25, 2001 12:21 PM
To: [EMAIL PROTECTED]
Subject: [JDBC] downloading image blobs
Hello,
I am having a similary problem that I was having when I was trying to
upload an image to the database. I am already able to upload blobs into
the database but I cannot download them.
I get the error 'inv_open: large object 12992 not found', which I assume
means that the statement should be in a transaction, but it is and it
still outputs the error.
Here is my code:
con.setAutoCommit(false);
Statement statement = con.createStatement();
ResultSet rs = statement.executeQuery("select image from
userpreferences where username='"+user+"'");
if(rs == null) return null;
rs.next();
InputStream is = rs.getBinaryStream("image"); <- This is
where the error is thrown
JimiReader reader = Jimi.createJimiReader(is);
image = reader.getImage();
con.commit();
con.close();
return new ServerMessage(new JimiImageSerializer(image));
Here is my error stack trace:
FastPath call returned ERROR: inv_open: large object 12992 not found
at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:126)
at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:176)
at org.postgresql.fastpath.Fastpath.getInteger(Fastpath.java:188)
at
org.postgresql.largeobject.LargeObject.(LargeObject.java:89)
at
org.postgresql.largeobject.LargeObjectManager.open(LargeObjectManager.java:1
34)
at
org.postgresql.jdbc2.ResultSet.getBinaryStream(ResultSet.java:437)
at
org.postgresql.jdbc2.ResultSet.getBinaryStream(ResultSet.java:544)
at
org.opensimpx.server.RequestHandler.getBackgroundImage(RequestHandler.java:6
88)
at
org.opensimpx.server.RequestHandler.handleRequest(RequestHandler.java:440)
at org.opensimpx.server.RequestHandler.run(RequestHandler.java:221)
at java.lang.Thread.run(Thread.java:479)
Any ideas?
Thank you in advanced,
Matt
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
we use a hashtable with connections as keys and timestamps as values...we do that so that we can clean up connections that haven't been used in a while...i know that some DBs invalidate their connections after a certain amount of time, so we have a process that periodically walks through the timestamps and cleans as necessary... anyway, this could be handled just as easily with a linked list of wrapped connections. can either of you suggest why the hashtable approach might be causing a problem? or is it probably elsewhere in my code? dave, if you have no trouble with donating your code, i would be more than happy to take a look at it...i'd really appreciate that. thanks for your help. chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Cramer Sent: Thursday, September 06, 2001 9:10 PM To: [EMAIL PROTECTED] Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... AFAIR, I simply wrap the sql connection for ease of handling, and then put available connections in the linked list. When I want one I remove it from the linked list, and put it into a hashtable, keyed by the toString method on the connection. When it is returned, I remove it from the hash table and put it back into the linked list Since it's a linked list, it can grow and shrink at will. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: September 6, 2001 8:14 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... I also built a linked list of available connections today and my problem has completly gone away. I have an intensly threaded app and it has been running now for several hours doing 1000's of inserts without the problem I was having before. I don't know how dave implemented his list but I have an inner class with a connection and a boolean marking whether it is in use. each insert gets a connection that is not in use from the linked list and marks it in use until it is finished. I also built in the ability for the list to grow and shrink dynamically based on need. So if all connections are in use I will create more and after a specified period of time I delete the ones that haven't been used. This seems to be working quite nicely now. t.r. -Original Message- From: Dave Cramer [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 6:05 PM To: [EMAIL PROTECTED]; Missner, T. R.; [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... Chris, I'm curious; why are you using a hashtable for available connections, and how do you use it? I have been using a connection pool that uses a linked list, in LIFO mode to store available connections. I can donate the pool code if need be, it has been running for over a year with no problems. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of chris markiewicz Sent: September 6, 2001 2:58 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... spoke too soon. i see the error again (with 7.1) ...i no longer get the transaction isolation level issue, but i still get the "NOTICE: current trans..." error. some improvement, i guess. whether it's active? that isn't ever really an issue with our approach, unless i'm misunderstanding your question...this is an oversimplification, but: we have a connection pool that has a hashtable of "available" connections...there is also a user-connection hashtable with users as keys and connections as values. if a user wants to hit the db, the system first checks the user-connection hashtable. if no conn is associated with the user, it grabs a connection from "available" connection hashtable and puts it in the user-connection hashtable. the user then uses that connection etc etc...when the transaction is closed (by our system code) the connection is "committed," removed from the the user-connection hashtable, and returned to the "available" hashtable. we don't use any threading, so there would never be two threads trying to use the same connection. should i be checking for anything else? thanks chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 2:29 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... I am in the process of rewriting my connection pooling object. I'll share the results when i am finished later today I suspect. How are you determining whether a transaction is active? getAutoCommit? -Original Message- From: chris markiewi
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
trm i have been able to successfully avoid the problem for the last 20 minutes or so...my connection pooling system calls commit() on connections before returning them to the "available" pool (even if they were already 'committed')...i added a conditional to check whether or not it was already committed - if it was, i don't run the commit. this seems to prevent the "transaction isolation level" exception that always preceded my other exceptions. might this apply to your pooling system as well? thanks chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 10:33 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... I really don't understand why this is happening either. my current guess is that there is something going on in the way we are reusing connections. To answer your question I don't think there is any relationship between the 2 connections just that after the first one is corrupted I use the second one until it gets corrupted, then create new ones and start again. I have to assume that we are doing something wrong in our use of these connections and am focusing my effort in that direction right now. Sure wish one of the experts would chime in on this. t.r. -Original Message- From: chris markiewicz [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 7:17 AM To: Missner, T. R.; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... tr things have gotten a little worse...i recently upgraded to postgresql 7.1 and now i am seeing this behavior even WITHOUT large objects. it happens much less frequently without LOs, but it still happens. i never saw this behavior in 7.0. are you seeing the same behavior? i guess i don't understand the following: right, each connection is a different process. so if you use the second connection, why should it fail too? it should have no relationship to the first connection, since it is a different process. i was discussing this with a co-worker and he suggested that the first connection might be "spilling" into the second (when you grab the first two connections, they may inhabit contiguous memory spaces...the first one gets corrupted and corrupts the second...i admit that i am no unix expert so while i can picture such a thing, i have no idea whether or not it is possible.) anyway, you grab the third connection and it's not corrupt. does that make any sense? chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 12:45 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... What I have is a connection pool. I initially grab 2 connections, one primary one secondary. If the insert fails on the primary connection I try the secondary, if it fails I simply delete the 2 I have and grab 2 more from the connection pool. After creating the new ones I have never seen it fail the first few times which is what leads me to believe that something in the connection itself is getting corrupted over time. Note that each connection is a separate process in the unix environment. I believe it is this process that is getting corrupted note necessarily the java connection wrapper. Of course this is all guess work right now. I'll let you know if I come up with a better solution or are able to determine why these connections act like they are getting corrupt. -Original Message- From: chris markiewicz [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 5:42 AM To: Missner, T. R.; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... follow-up question - you say that if you get one exception, you try the insert with another connection...if that doesn't work you delete the existing connections and get new ones... i must be missing something - why wouldn't using the second connection always work? if you get rid of the offending connection (the first one), why does the second one have a problem? or am i confusing your connection object with the actual connection? thanks chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 04, 2001 3:35 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... Chris, I had the same problem on the insert side and thought it went away but it is back and I am convinced it is related to more than one thread using the same connection at the same time. What I have done as a work around in the interim ( until I write my own connection manager class ) is catch the exception an
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
the 7.1 driver that i am using was downloaded from http://jdbc.fastcrypt.com. is that the right spot? chris -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 12:40 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... "chris markiewicz" <[EMAIL PROTECTED]> writes: > i do agree that since everyone isn't complaining, the problem is likely in > my code. the odd thing is that i wasn't seeing this behavior with the 7.0 > stuff, only with the 7.1. Hmm. Are you using the JDBC driver that was released with 7.1? That seems to have been rather buggy. You might want to grab the latest version of the driver (I forget the URL but it's been mentioned repeatedly on this list). regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
new info...maybe it's too early to say, but it seems that i only have this problem with 7.1...i just went back to 7.0 db and jdbc driver and now i am running without incident... t.r. - what are you running? have any connection parameters changed? is there anything i need to change in order to upgrade to 7.1? (other than that rs.absolute(index + 1) thing)? for a brief period, i was running 7.0 with the 7.1 drivers and i was getting the same behavior...don't know if that means anything to anyone... a brief history of how i got here: for the past year i have been running 7.0 with one problem - fastpath errors. i recently decided to make the upgrade to 7.1 with the hopes that i might get more info on my FP problem. so i switched and started getting the errors that we have been discussing here - whether or not i work with Large Objects. i have noticed one other pattern - this might be very important: it seems like my set of errors is always preceded by one of those "must set transaction isolation level..." messages. to be more precise, it is always preceded by the system trying to commit all connections that are associated with a user so that they can throw them back to the "available" connection pool. when this commit() is run, i get the transaction isolation level exception, then everything falls apart. will this happen if i call commit on a conn that was already committed? what causes that error to be thrown??? thanks chris -Original Message- From: admin [mailto:admin]On Behalf Of Antonio Fiol Bonnin Sent: Thursday, September 06, 2001 11:47 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... I understand. However, doesn't the exception automatically do some kind of rollback? I can't remember where I read such a thing... Antonio chris markiewicz wrote: > antonio > > thanks. it actually does apply to some degree. i have noticed that rolling > back the connection will sometimes prevent subsequent errors, but for some > reason it is not completely predictable... > > the bigger issue is that the db is throwing errors that i don't understand. > i might have just discovered a pattern - i'll post it as soon as i am more > certain of it. but rolling back whenever i get an unpredictable exception > will kill any transaction. this is a problem. it will also require some > localized but non-trivial rework in the persistence layer. i really don't > want to do that unless i have no other avenues. > > thanks for your response. > > chris > > -Original Message- > From: admin [mailto:admin]On Behalf Of Antonio Fiol Bonnin > Sent: Thursday, September 06, 2001 11:18 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... > > I'm no expert at all, but, --forgive me!!-- have you tried to roll back upon > the first exception you get? > > Or maybe try to get the warnings in your ResultSet to see if something is > there, though I do not remember having done so. > > I remember having something similar when I tried to read from a table that > did > not exist (mangled name). That request throwed an exception, and if I > ignored > the exception, all subsequent requests did show this kind of behaviour, or a > similar one. > > Forget my message if it doesn't apply to your problem, please. > > Antonio Fiol > > [EMAIL PROTECTED] wrote: > > > I really don't understand why this is happening either. > > my current guess is that there is something going on > > in the way we are reusing connections. To answer your > > question I don't think there is any relationship between the > > 2 connections just that after the first one is corrupted > > I use the second one until it gets corrupted, then > > create new ones and start again. I have to assume > > that we are doing something wrong in our use of > > these connections and am focusing my effort in that > > direction right now. > > > > Sure wish one of the experts would chime in on this. > > > > t.r. > > > > -Original Message- > > From: chris markiewicz [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 06, 2001 7:17 AM > > To: Missner, T. R.; [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... > > > > tr > > > > things have gotten a little worse...i recently upgraded to postgresql 7.1 > > and now i am seeing this behavior even WITHOUT large objects. it happens > > much less frequently without LOs, but it still happens. i never saw this &g
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
tom i do agree that since everyone isn't complaining, the problem is likely in my code. the odd thing is that i wasn't seeing this behavior with the 7.0 stuff, only with the 7.1. (i was having the fastpath problem with 7.0, but that's a different issue.) i'm looking... thanks chris -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 12:10 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... "chris markiewicz" <[EMAIL PROTECTED]> writes: > i guess i don't understand the following: right, each connection is a > different process. so if you use the second connection, why should it fail > too? it should have no relationship to the first connection, since it is a > different process. > i was discussing this with a co-worker and he suggested that the first > connection might be "spilling" into the second (when you grab the first two > connections, they may inhabit contiguous memory spaces...the first one gets > corrupted and corrupts the second...i admit that i am no unix expert so > while i can picture such a thing, i have no idea whether or not it is > possible.) anyway, you grab the third connection and it's not > corrupt. It seems to me that this must be happening on the client side somewhere. On the server side, two different connections will lead to completely separate processes which are very well insulated from each other. OTOH, we've seen numerous reports of problems with connection-pooling applications that got confused about which connection they were using for what. I don't have any real evidence to guess whether the fault is in your own application code or in the JDBC driver. However, if it were in the driver we'd probably be hearing more reports of trouble ... so I'd suggest looking to your own code first ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
that's a good point...when this error occurs, i suppose the connection is defunct and any transaction is already lost. chris -Original Message- From: admin [mailto:admin]On Behalf Of Antonio Fiol Bonnin Sent: Thursday, September 06, 2001 11:47 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... I understand. However, doesn't the exception automatically do some kind of rollback? I can't remember where I read such a thing... Antonio chris markiewicz wrote: > antonio > > thanks. it actually does apply to some degree. i have noticed that rolling > back the connection will sometimes prevent subsequent errors, but for some > reason it is not completely predictable... > > the bigger issue is that the db is throwing errors that i don't understand. > i might have just discovered a pattern - i'll post it as soon as i am more > certain of it. but rolling back whenever i get an unpredictable exception > will kill any transaction. this is a problem. it will also require some > localized but non-trivial rework in the persistence layer. i really don't > want to do that unless i have no other avenues. > > thanks for your response. > > chris > > -Original Message- > From: admin [mailto:admin]On Behalf Of Antonio Fiol Bonnin > Sent: Thursday, September 06, 2001 11:18 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... > > I'm no expert at all, but, --forgive me!!-- have you tried to roll back upon > the first exception you get? > > Or maybe try to get the warnings in your ResultSet to see if something is > there, though I do not remember having done so. > > I remember having something similar when I tried to read from a table that > did > not exist (mangled name). That request throwed an exception, and if I > ignored > the exception, all subsequent requests did show this kind of behaviour, or a > similar one. > > Forget my message if it doesn't apply to your problem, please. > > Antonio Fiol > > [EMAIL PROTECTED] wrote: > > > I really don't understand why this is happening either. > > my current guess is that there is something going on > > in the way we are reusing connections. To answer your > > question I don't think there is any relationship between the > > 2 connections just that after the first one is corrupted > > I use the second one until it gets corrupted, then > > create new ones and start again. I have to assume > > that we are doing something wrong in our use of > > these connections and am focusing my effort in that > > direction right now. > > > > Sure wish one of the experts would chime in on this. > > > > t.r. > > > > -Original Message- > > From: chris markiewicz [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 06, 2001 7:17 AM > > To: Missner, T. R.; [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... > > > > tr > > > > things have gotten a little worse...i recently upgraded to postgresql 7.1 > > and now i am seeing this behavior even WITHOUT large objects. it happens > > much less frequently without LOs, but it still happens. i never saw this > > behavior in 7.0. are you seeing the same behavior? > > > > i guess i don't understand the following: right, each connection is a > > different process. so if you use the second connection, why should it > fail > > too? it should have no relationship to the first connection, since it is > a > > different process. > > i was discussing this with a co-worker and he suggested that the first > > connection might be "spilling" into the second (when you grab the first > two > > connections, they may inhabit contiguous memory spaces...the first one > gets > > corrupted and corrupts the second...i admit that i am no unix expert so > > while i can picture such a thing, i have no idea whether or not it is > > possible.) anyway, you grab the third connection and it's not corrupt. > > does that make any sense? > > > > chris > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, September 05, 2001 12:45 PM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... > > > > What I have is a connection pool. > > I initially grab 2
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
tr things have gotten a little worse...i recently upgraded to postgresql 7.1 and now i am seeing this behavior even WITHOUT large objects. it happens much less frequently without LOs, but it still happens. i never saw this behavior in 7.0. are you seeing the same behavior? i guess i don't understand the following: right, each connection is a different process. so if you use the second connection, why should it fail too? it should have no relationship to the first connection, since it is a different process. i was discussing this with a co-worker and he suggested that the first connection might be "spilling" into the second (when you grab the first two connections, they may inhabit contiguous memory spaces...the first one gets corrupted and corrupts the second...i admit that i am no unix expert so while i can picture such a thing, i have no idea whether or not it is possible.) anyway, you grab the third connection and it's not corrupt. does that make any sense? chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 12:45 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... What I have is a connection pool. I initially grab 2 connections, one primary one secondary. If the insert fails on the primary connection I try the secondary, if it fails I simply delete the 2 I have and grab 2 more from the connection pool. After creating the new ones I have never seen it fail the first few times which is what leads me to believe that something in the connection itself is getting corrupted over time. Note that each connection is a separate process in the unix environment. I believe it is this process that is getting corrupted note necessarily the java connection wrapper. Of course this is all guess work right now. I'll let you know if I come up with a better solution or are able to determine why these connections act like they are getting corrupt. -Original Message----- From: chris markiewicz [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 5:42 AM To: Missner, T. R.; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... follow-up question - you say that if you get one exception, you try the insert with another connection...if that doesn't work you delete the existing connections and get new ones... i must be missing something - why wouldn't using the second connection always work? if you get rid of the offending connection (the first one), why does the second one have a problem? or am i confusing your connection object with the actual connection? thanks chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 04, 2001 3:35 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... Chris, I had the same problem on the insert side and thought it went away but it is back and I am convinced it is related to more than one thread using the same connection at the same time. What I have done as a work around in the interim ( until I write my own connection manager class ) is catch the exception and try the insert again with another connection. If it still fails I delete the connections I have and create new ones and the insert ALWAYS works after that. So it appears to me that something is happening to my connection object that is causing it to get corrupted to some extent. Once a connection throws this exception it seems much more likely to do so again which is why I am deleting connections and creating new ones if I have 2 failures back to back. This isn't the answer you are looking for but I hoped it might help you think of other ways to troubleshoot your problem. Since I put this work around in I have been able to run a very high rate and haven't lost any data on the insert side. My guess is that these Fastpath transactions are very slow compared to non fastpath transactions and it is easy to use a connection that hasn't finished what it is doing. I even used a synchronized method to hopefully block on the connection but this didn't fix the problem either. Must be some threading going on in the connection class. I haven't had the time to go through the code but I will at some point. I know someone out there has some insight that could help. t.r. missner level(3) communications -Original Message- From: chris markiewicz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 04, 2001 11:40 AM To: [EMAIL PROTECTED]; 'Postgres Jdbc (E-mail)' Cc: [EMAIL PROTECTED] Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... hello. i have some more details on this problem...i found the reference to calling rollback when you get this sort of e
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
follow-up question - you say that if you get one exception, you try the
insert with another connection...if that doesn't work you delete the
existing connections and get new ones...
i must be missing something - why wouldn't using the second connection
always work? if you get rid of the offending connection (the first one),
why does the second one have a problem? or am i confusing your connection
object with the actual connection?
thanks
chris
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 3:35 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
Chris,
I had the same problem on the insert side and thought it went away but
it is back and I am convinced it is related to more than one thread using
the same connection at the same time. What I have done as a work around
in the interim ( until I write my own connection manager class ) is catch
the exception and try the insert again with another connection. If it still
fails I delete the connections I have and create new ones and the insert
ALWAYS works after that. So it appears to me that something is happening
to my connection object that is causing it to get corrupted to some extent.
Once a connection throws this exception it seems much more likely to do so
again which is why I am deleting connections and creating new ones if I have
2 failures back to back. This isn't the answer you are looking for but
I hoped it might help you think of other ways to troubleshoot your problem.
Since I put this work around in I have been able to run a very high rate
and haven't lost any data on the insert side. My guess is that these
Fastpath
transactions are very slow compared to non fastpath transactions and it
is easy to use a connection that hasn't finished what it is doing.
I even used a synchronized method to hopefully block on the connection
but this didn't fix the problem either. Must be some threading going on
in the connection class. I haven't had the time to go through the code
but I will at some point.
I know someone out there has some insight that could help.
t.r. missner
level(3) communications
-----Original Message-
From: chris markiewicz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 11:40 AM
To: [EMAIL PROTECTED]; 'Postgres Jdbc (E-mail)'
Cc: [EMAIL PROTECTED]
Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
hello. i have some more details on this problem...i found the reference to
calling rollback when you get this sort of error.
(http://fts.postgresql.org/db/mw/msg.html?mid=1030879)... i have started
doing that, but i am still getting the problem.
i have the setup shown below...i've learned that i can usually get around
the fastpath error if i try the query a few times...so i make it call up to
10 times if there is an error...the po.load() call runs the (SELECT
versionid, versionid, versioncomment, versionlabel, creatorid, documentid,
versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034272) query from the last message i
sent (see below)...if that throws an exception, i catch it, rollback, and
contine...i am still seeing the same behavior though...
public void loadComplex(User user) throws SBHException {
int iterations = 10;
try {
//## TODO:
//## occasionally get a fastpath exception here...try to
//## call load() as many as 10 times if there is an exception...
//## this is here only as a test...
//## chris markiewicz
int i = 0;
boolean exceptionfound = false;
boolean goodResult = false;
while (!goodResult && i < iterations) {
try {
i++;
dv = (DocumentVersion)po.load(versionid, user);
goodResult = true;
} catch (Exception e) {
System.out.println("SBHDocument.loadComplex exception
attempt:"+i);
try {po.rollback(user);} catch (Exception e3) {...log
here...}
exceptionfound = true;
Log.log("SBHDocument.loadComplex attempt:"+i);
Log.log("SBHDocument.loadComplex e:"+e);
if (i == (iterations - 1)) {
throw e;
}
}
}
if (exceptionfound) {
...log here...
}
} catch (TransactionException te) {
throw te;
} catch (SBHSecurityException sse) {
throw sse;
} catch (SBHException sbe) {
throw sbe;
} catch (Exception e) {
throw new SBHException(e);
}
}
here is the log calling that query many times:
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
t.r.
thank you very much for this information...while i suppose you're right that
it's not as good as a fix, it is much better than the brick wall that i've
been facing (my app cannot be shipped in its current state). your
workaround should be relatively easy to implement and i can't argue with
your success rate!
thanks again, and i'll let you know if i learn anything new.
chris
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 3:35 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
Chris,
I had the same problem on the insert side and thought it went away but
it is back and I am convinced it is related to more than one thread using
the same connection at the same time. What I have done as a work around
in the interim ( until I write my own connection manager class ) is catch
the exception and try the insert again with another connection. If it still
fails I delete the connections I have and create new ones and the insert
ALWAYS works after that. So it appears to me that something is happening
to my connection object that is causing it to get corrupted to some extent.
Once a connection throws this exception it seems much more likely to do so
again which is why I am deleting connections and creating new ones if I have
2 failures back to back. This isn't the answer you are looking for but
I hoped it might help you think of other ways to troubleshoot your problem.
Since I put this work around in I have been able to run a very high rate
and haven't lost any data on the insert side. My guess is that these
Fastpath
transactions are very slow compared to non fastpath transactions and it
is easy to use a connection that hasn't finished what it is doing.
I even used a synchronized method to hopefully block on the connection
but this didn't fix the problem either. Must be some threading going on
in the connection class. I haven't had the time to go through the code
but I will at some point.
I know someone out there has some insight that could help.
t.r. missner
level(3) communications
-Original Message-
From: chris markiewicz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 11:40 AM
To: [EMAIL PROTECTED]; 'Postgres Jdbc (E-mail)'
Cc: [EMAIL PROTECTED]
Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
hello. i have some more details on this problem...i found the reference to
calling rollback when you get this sort of error.
(http://fts.postgresql.org/db/mw/msg.html?mid=1030879)... i have started
doing that, but i am still getting the problem.
i have the setup shown below...i've learned that i can usually get around
the fastpath error if i try the query a few times...so i make it call up to
10 times if there is an error...the po.load() call runs the (SELECT
versionid, versionid, versioncomment, versionlabel, creatorid, documentid,
versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034272) query from the last message i
sent (see below)...if that throws an exception, i catch it, rollback, and
contine...i am still seeing the same behavior though...
public void loadComplex(User user) throws SBHException {
int iterations = 10;
try {
//## TODO:
//## occasionally get a fastpath exception here...try to
//## call load() as many as 10 times if there is an exception...
//## this is here only as a test...
//## chris markiewicz
int i = 0;
boolean exceptionfound = false;
boolean goodResult = false;
while (!goodResult && i < iterations) {
try {
i++;
dv = (DocumentVersion)po.load(versionid, user);
goodResult = true;
} catch (Exception e) {
System.out.println("SBHDocument.loadComplex exception
attempt:"+i);
try {po.rollback(user);} catch (Exception e3) {...log
here...}
exceptionfound = true;
Log.log("SBHDocument.loadComplex attempt:"+i);
Log.log("SBHDocument.loadComplex e:"+e);
if (i == (iterations - 1)) {
throw e;
}
}
}
if (exceptionfound) {
...log here...
}
} catch (TransactionException te) {
throw te;
} catch (SBHSecurityException sse) {
throw sse;
} catch (SBHException sbe) {
throw sbe;
} catch (Exception e) {
throw new SBHException(e);
}
}
here is the log calling that query many times:
DEBUG: StartTransactionCommand
DEBUG: query:
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
hello. yet another follow-on to my questions...is there a way to determine
whether i am going to get this "NOTICE" before i execute a query? check
some status code or something?
thanks
chris
-Original Message-----
From: Chris Markiewicz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 1:40 PM
To: [EMAIL PROTECTED]; 'Postgres Jdbc (E-mail)'
Cc: [EMAIL PROTECTED]
Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
hello. i have some more details on this problem...i found the reference to
calling rollback when you get this sort of error.
(http://fts.postgresql.org/db/mw/msg.html?mid=1030879)... i have started
doing that, but i am still getting the problem.
i have the setup shown below...i've learned that i can usually get around
the fastpath error if i try the query a few times...so i make it call up to
10 times if there is an error...the po.load() call runs the (SELECT
versionid, versionid, versioncomment, versionlabel, creatorid, documentid,
versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034272) query from the last message i
sent (see below)...if that throws an exception, i catch it, rollback, and
contine...i am still seeing the same behavior though...
public void loadComplex(User user) throws SBHException {
int iterations = 10;
try {
//## TODO:
//## occasionally get a fastpath exception here...try to
//## call load() as many as 10 times if there is an exception...
//## this is here only as a test...
//## chris markiewicz
int i = 0;
boolean exceptionfound = false;
boolean goodResult = false;
while (!goodResult && i < iterations) {
try {
i++;
dv = (DocumentVersion)po.load(versionid, user);
goodResult = true;
} catch (Exception e) {
System.out.println("SBHDocument.loadComplex exception
attempt:"+i);
try {po.rollback(user);} catch (Exception e3) {...log
here...}
exceptionfound = true;
Log.log("SBHDocument.loadComplex attempt:"+i);
Log.log("SBHDocument.loadComplex e:"+e);
if (i == (iterations - 1)) {
throw e;
}
}
}
if (exceptionfound) {
...log here...
}
} catch (TransactionException te) {
throw te;
} catch (SBHSecurityException sse) {
throw sse;
} catch (SBHException sbe) {
throw sbe;
} catch (Exception e) {
throw new SBHException(e);
}
}
here is the log calling that query many times:
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
chris
-Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of chris markiewicz
Sent: Tuesday, September 04, 2001 11:42 AM
To: Postgres Jdbc (E-mail)
Cc: [EMAIL PROTECTED]
Subject: [JDBC] error - NOTICE: current transaction is aborted, queries
ignored until end of transaction block
Hello.
I have been having problems with postgresql large objects...i
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
hello. i have some more details on this problem...i found the reference to
calling rollback when you get this sort of error.
(http://fts.postgresql.org/db/mw/msg.html?mid=1030879)... i have started
doing that, but i am still getting the problem.
i have the setup shown below...i've learned that i can usually get around
the fastpath error if i try the query a few times...so i make it call up to
10 times if there is an error...the po.load() call runs the (SELECT
versionid, versionid, versioncomment, versionlabel, creatorid, documentid,
versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034272) query from the last message i
sent (see below)...if that throws an exception, i catch it, rollback, and
contine...i am still seeing the same behavior though...
public void loadComplex(User user) throws SBHException {
int iterations = 10;
try {
//## TODO:
//## occasionally get a fastpath exception here...try to
//## call load() as many as 10 times if there is an exception...
//## this is here only as a test...
//## chris markiewicz
int i = 0;
boolean exceptionfound = false;
boolean goodResult = false;
while (!goodResult && i < iterations) {
try {
i++;
dv = (DocumentVersion)po.load(versionid, user);
goodResult = true;
} catch (Exception e) {
System.out.println("SBHDocument.loadComplex exception
attempt:"+i);
try {po.rollback(user);} catch (Exception e3) {...log
here...}
exceptionfound = true;
Log.log("SBHDocument.loadComplex attempt:"+i);
Log.log("SBHDocument.loadComplex e:"+e);
if (i == (iterations - 1)) {
throw e;
}
}
}
if (exceptionfound) {
...log here...
}
} catch (TransactionException te) {
throw te;
} catch (SBHSecurityException sse) {
throw sse;
} catch (SBHException sbe) {
throw sbe;
} catch (Exception e) {
throw new SBHException(e);
}
}
here is the log calling that query many times:
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of chris markiewicz
Sent: Tuesday, September 04, 2001 11:42 AM
To: Postgres Jdbc (E-mail)
Cc: [EMAIL PROTECTED]
Subject: [JDBC] error - NOTICE: current transaction is aborted, queries
ignored until end of transaction block
Hello.
I have been having problems with postgresql large objects...i have been
searching the archives of this group and i have posted a question or two but
i have so far be unable to resolve the issues. right now, i have a screen
that loads a few LOs...they occasionally don't make it to the screen. i see
a couple of different errors in my log files (which i included below). i
turned on debugging (d2) and i see the following on many of my queries (see
below).
DEBUG: StartTransactionCommand
DEBUG: query: SELECT DISTINCT sbhd.time
[JDBC] error - NOTICE: current transaction is aborted, queries ignored until end of transaction block
Hello. I have been having problems with postgresql large objects...i have been searching the archives of this group and i have posted a question or two but i have so far be unable to resolve the issues. right now, i have a screen that loads a few LOs...they occasionally don't make it to the screen. i see a couple of different errors in my log files (which i included below). i turned on debugging (d2) and i see the following on many of my queries (see below). DEBUG: StartTransactionCommand DEBUG: query: SELECT DISTINCT sbhd.timestamp AS "modifydate", sbhd.versionid AS "versionid", sbhd.documentdescription AS "sbhdocumentdescription", sbhd.maxversions AS "maxversions", sbhd.documentid AS "sbhdocumentid", sbhd.hidden AS "hidden", sbhd.documentpath AS "sbhdocumentpath", sbhd.parentid AS "parentid", sbhd.ownerid AS "ownerid", sbhd.documentname AS "sbhdocumentname", sbhd.createtimestamp AS "createdate" FROM document sbhd WHERE sbhd.documentpath = '/cmarkiew/porsche/porsche_speedster.jpg' DEBUG: ProcessQuery DEBUG: CommitTransactionCommand DEBUG: StartTransactionCommand DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel, creatorid, documentid, versionorder, datestamp, versioncontent FROM document_version WHERE versionid = 1034272 NOTICE: current transaction is aborted, queries ignored until end of transaction block DEBUG: CommitTransactionCommand DEBUG: StartTransactionCommand DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel, creatorid, documentid, versionorder, datestamp, versioncontent FROM document_version WHERE versionid = 1034272 NOTICE: current transaction is aborted, queries ignored until end of transaction block DEBUG: CommitTransactionCommand what causes the "current transaction is aborted, queries ignored until end of transaction block?" the first query in the above debug block does not load an LO, but the second one does. after the second query, seems like all subsequent have that message...my log file starts getting a bunch of the following: No results were returned by the query. at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:63) at com.commnav.sbh.framework.persist.JDBCEngine.load(JDBCEngine.java:274) at com.commnav.sbh.framework.persist.PersistenceObject.load(PersistenceObject.j ava:169) at com.commnav.sbh.framework.documentmanager.SBHDocument.loadComplex(SBHDocumen t.java:402) at com.commnav.sbh.framework.documentmanager.SBHDocument.getSBHDocument(SBHDocu ment.java:363) at com.commnav.sbh.servlets.DocumentManager.doPost(DocumentManager.java:201) at com.commnav.sbh.servlets.CommnavServlet.doGet(CommnavServlet.java:170) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:484) No results were returned by the query. at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:63) at com.commnav.sbh.framework.persist.JDBCEngine.load(JDBCEngine.java:274) at com.commnav.sbh.framework.persist.PersistenceObject.load(PersistenceObject.j ava:169) at com.commnav.sbh.framework.documentmanager.SBHDocument.loadComplex(SBHDocumen t.java:402) at com.commnav.sbh.framework.documentmanager.SBHDocument.getSBHDocument(SBHDocu ment.java:363) at com.commnav.sbh.servlets.DocumentManager.doPost(DocumentManager.java:201) at com.commnav.sbh.servlets.CommnavServlet.doGet(CommnavServlet.java:170) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint
RE: [JDBC] next() and PreparedStatement
i believe that when you close the stmt, the rs is automatically closed. you have to leave the stmt open until you're done with the rs. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mano lito Sent: Tuesday, August 28, 2001 7:14 AM To: [EMAIL PROTECTED] Subject: [JDBC] next() and PreparedStatement Hi! We are developing a project using PostgreSQL 7.1.2 and JDBC drivers to exchange information with the database. Here is a piece of code to explain our problem: --- PreparedStatement pstmt; Connection connection; ResultSet rs = null; String query = new String( "SELECT count(*) FROM foo_table WHERE foo_code=?;" ); pstmt = connection.prepareStatement( query ); pstmt.setString( 1, foo ); rs = pstmt.executeQuery( query ); pstmt.close(); return rs.next(); -- the next() method will cause a java.lang.NullPointerException when the ResultSet comes from a PreparedStatement!!! Is this problem originated by the JDBC driver? We downloaded it from jdbc.fastcrypt.com but this error occurs again and again and in jdbc.postgresql.org we see 7.0.x drivers available but none 7.1 nor 7.1.2 exists... We'd appreciate any help you could give us.If your address is not the correct place to ask this questions please tell us. Thanks in advance. _ Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [JDBC] Fastpath error on solaris 2.8 pgsql 7.1.3
Tom, When I say that this problem is erratic, I mean that sometimes a given piece of code works and sometimes it doesn't - not that some pieces work and some don't (don't know if that helps). How is a BEGIN indicated? I get a Connection, grab a Statement from it, and run my query. Do I have to do anything special to tell Fastpath that I am BEGINning a transaction? Thanks chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane Sent: Monday, August 27, 2001 4:43 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JDBC] Fastpath error on solaris 2.8 pgsql 7.1.3 [EMAIL PROTECTED] writes: > FastPath call returned ERROR: lo_write: invalid large obj descriptor (0) Usually this indicates that you didn't have the lo_open ... lo_write ... lo_close sequence wrapped in a transaction block (BEGIN/COMMIT SQL commands). Since it's erratic for you, I'd bet that some of your application control paths have the BEGIN and some don't. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [JDBC] Fastpath error on solaris 2.8 pgsql 7.1.3
I have exactly the same problem...it happens randomly, it seems. maybe 5% of the time. also happens on selects (lo_read though). the only advice that i've seen on the topic is to make sure that autocommit is set to false, which i've done, but i still see the problem. unfortunately, my next attempt at a fix was going to be to upgrade to 7.1 (i'm currently on 7.0.3 on linux)...but i see that you already use 7.1... sorry i can't help... chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, August 27, 2001 11:51 AM To: [EMAIL PROTECTED] Subject: [JDBC] Fastpath error on solaris 2.8 pgsql 7.1.3 Anyone seen this error before? It doesn't happen every time I insert a blob so I assume the code is correct. Only happens occasionaly. I have no idea how to troubleshoot this problem. Any help would be appreciated. FastPath call returned ERROR: lo_write: invalid large obj descriptor (0) I don't know if this is related to JDBC or not but the code I am using to insert the blob is JDBC. t.r. missner level 3 communications ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[JDBC] ERROR: SET TRANSACTION ISOLATION LEVEL must be called before any query
In addition to the error that I mentioned in my earlier post ("No results"
exception on executeQuery() - see below), I get the following when I try to
commit a connection:
java.sql.SQLException: ERROR: SET TRANSACTION ISOLATION LEVEL must be
called before any query
at org.postgresql.Connection.ExecSQL(Connection.java:548)
at org.postgresql.Connection.ExecSQL(Connection.java:415)
at org.postgresql.jdbc2.Connection.doIsolationLevel(Connection.java:412)
at org.postgresql.jdbc2.Connection.commit(Connection.java:226)
at
com.commnav.sbh.framework.persist.JDBCConnection.commit(JDBCConnection.java:
312)
at
com.commnav.sbh.framework.persist.ConnectionManager.commitConnections(Connec
tionManager.java:366)
at
com.commnav.sbh.framework.persist.ConnectionManager.removeConnectionManager(
ConnectionManager.java:204)
at com.commnav.sbh.objects.User.finalize(User.java:162)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:86)
at java.lang.ref.Finalizer.access$100(Finalizer.java:17)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:163)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of chris markiewicz
Sent: Thursday, August 16, 2001 12:47 PM
To: [EMAIL PROTECTED]
Subject: [JDBC] "No results" exception on executeQuery()
Hello. I just update my driver to the latest version (7.1-1.3). I am
seeing MANY of the following exception:
No results were returned by the query.
at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:63)
at
com.commnav.sbh.framework.persist.JDBCEngine.executeQuery(JDBCEngine.java:22
1)
at
com.commnav.sbh.framework.persist.PersistenceObject.query(PersistenceObject.
java:1046)
...
I checked the history of this listserv and found some related but not quite
relevant stuff (part of the thread is below - it talks about using
executeUpdate for update/insert/delete)...
I am sometimes getting this exception even when there should be results
returned...
I appreciate any help.
chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2001 2:50 PM
To: [EMAIL PROTECTED]
Subject: [JDBC] "No results" exception on insert
Hello,
I have some code which is essentially doing the following:
Statement stmt;
ResultSet rs = stmt.executeQuery("insert into users values ( 'joe', 'blow'
)");
The values are inserted into the table correctly. I verified this using
psql:
"select * from users".
The problem is that the executeQuery throws an Exception. The message
is "No results were returned by the query":
No results were returned by the query.
at org.postgresql.jdbc2.Statement.executeQuery(Statement.java,
Compiled
Code)
My driver is "org.postgresql.Driver" from the jar file jdbc7.0-1.2.jar. I
think
the port version is 7.1 The platform is FreeBSD 4.2-RELEASE.
I am using linux jdk 1.2.2.
Can anyone give me any ideas?
Thanks,
Brian
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[JDBC] "No results" exception on executeQuery()
Hello. I just update my driver to the latest version (7.1-1.3). I am
seeing MANY of the following exception:
No results were returned by the query.
at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:63)
at
com.commnav.sbh.framework.persist.JDBCEngine.executeQuery(JDBCEngine.java:22
1)
at
com.commnav.sbh.framework.persist.PersistenceObject.query(PersistenceObject.
java:1046)
...
I checked the history of this listserv and found some related but not quite
relevant stuff (part of the thread is below - it talks about using
executeUpdate for update/insert/delete)...
I am sometimes getting this exception even when there should be results
returned...
I appreciate any help.
chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2001 2:50 PM
To: [EMAIL PROTECTED]
Subject: [JDBC] "No results" exception on insert
Hello,
I have some code which is essentially doing the following:
Statement stmt;
ResultSet rs = stmt.executeQuery("insert into users values ( 'joe', 'blow'
)");
The values are inserted into the table correctly. I verified this using
psql:
"select * from users".
The problem is that the executeQuery throws an Exception. The message
is "No results were returned by the query":
No results were returned by the query.
at org.postgresql.jdbc2.Statement.executeQuery(Statement.java,
Compiled
Code)
My driver is "org.postgresql.Driver" from the jar file jdbc7.0-1.2.jar. I
think
the port version is 7.1 The platform is FreeBSD 4.2-RELEASE.
I am using linux jdk 1.2.2.
Can anyone give me any ideas?
Thanks,
Brian
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
RE: [JDBC] hangs while getting large objects...
While I can readily reproduce it on my application, I have so far been
unsuccessful at writing a test case that reproduces the problem.
Oh, I just tried the latest drivers - no luck - same problem.
Equally unfortunate is the fact that all database processing is heavily
abstracted in the application - so there is no method that grabs a
connection, performs the query, iterates through the ResultSet, and closes
the rs/stmt/conn. I know that I am unlikely to find help unless I can
manage to reproduce the problem on an independent program, but I was hoping
that there might be some general LO or byte stream rule that I am not
following.
The area where is breaks is shown below. The method grabs the column name
from RS metadata and calls either getObject or getBytes. When it hangs, it
occurs on the getBytes(...) line.
Once it hangs, the system is essentially useless. My test program will
freeze when it reaches the particular row that the application is trying to
access. The application hangs on to the commection until I stop Tomcat.
I'll continue trying to reproduce in a separate program.
thanks
chris
if (sqlf.getGetType().equals("byte[]")) {
try {
System.out.println("JDBCE.getbytes (before)");
byte[] bytes = rs.getBytes(columnName);
System.out.println("JDBCE.getbytes (after)");
marshaller.setObjectField(o, sqlf.getMapField(), bytes);
} catch (Exception e) {
String exStr = e.toString();
//## create SBHException here so that it is logged
SBHException sbhex = new SBHException(e);
if (exStr.indexOf("FastPath") == -1) {
System.out.println("JDBCE.lrs NONFastPath error..."+exStr);
throw e;
} else {
System.out.println("JDBCE.lrs FastPath error..."+exStr);
throw new FastPathException(e);
}
}
} else {
result = rs.getObject(columnName);
marshaller.setObjectField(o, sqlf.getMapField(), result);
}
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[JDBC] hangs while getting large objects...
hello. i occasionally have problems getting large objects from postgres. i am confident that this problem is a problem with my code and not postgres because i cannot find similar complaints and no one responded to my question from earlier this month (appears later in this email). I have a screen that loads several LOs (small images, mostly). Occasionally the process hangs on the rs.getBytes() line. Does anyone know what could be causing this? Separately, I have written a simple program that queries the table with the LOs. No problems - unless I run it while my application is hanging (then the simple program hangs indefinitely as well). I am able to run queries from the command line while this is going on, so it seems like the byte stream is plugging things up, but everything else is fine. Does anyone have any ideas what the problem could be? Everything works perfectly 90% of the time, but 90% isn't that good. At this point, I'm not even sure what to try. Are there any Postgres configuration changes I could make? Would Postgres logging tell me anything. I greatly appreciate your help. note - i'm running 7.0.3 on linux...connecting through jdbc. chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of chris markiewicz Sent: Thursday, August 02, 2001 6:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [JDBC] errors while getting large objects... hello. my application uses large objects frequently...to render the main page, it might load anywhere from zero to 10 large objects - mostly images or documents. recently i started stress testing this page (making it always load many LOs) and i frequently encounter two different problems. 1. fastpath - autocommit is always false...i've verified this several times. my current workaround is to catch the fastpath error and resubmit the query...usually works on the second pass and rarely makes it to 4 passes (the current limit i have set). i have included a stack trace at the bottom of this message. does anyone have any ideas on this? i'm using 7.0.2 with the 7.0-1.2 jdbc driver. the occurences seem totally random...sometimes a page loads perfectly, sometimes i get three fastpath errors...sometimes the first load gets FP erros, sometimes the fifth page does. 2. hanging - i recently noticed that the processing sometimes (pretty frequently) hangs on the line of code that grabs the LO from the db...i've tried both: byte[] bytes = rs.getBytes(columnName); and InputStream is = rs.getBinaryStream(columnName); Same result for both. It hangs indefinitely. Similar to the fastpath - sometimes it happens, sometimes it doesn't...but it always happens within 5 screen loads of my stress test page. does anyone know if these problems were fixed in recent versions of postgresql? is anyone having similar problems? i greatly appreciate any help! thanks chris FastPath call returned ERROR: lo_tell: invalid large object descriptor (0) at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:141) at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:191) at org.postgresql.fastpath.Fastpath.getInteger(Fastpath.java:203) at org.postgresql.largeobject.LargeObject.tell(LargeObject.java:232) at org.postgresql.largeobject.LargeObject.size(LargeObject.java:247) at org.postgresql.jdbc2.ResultSet.getBytes(ResultSet.java:370) at org.postgresql.jdbc2.ResultSet.getBinaryStream(ResultSet.java:514) at org.postgresql.jdbc2.ResultSet.getBinaryStream(ResultSet.java:616) at com.commnav.sbh.framework.persist.JDBCEngine.loadResultSet(JDBCEngine.java:4 40) at com.commnav.sbh.framework.persist.JDBCEngine.load(JDBCEngine.java:284) at com.commnav.sbh.framework.persist.PersistenceObject.load(PersistenceObject.j ava:169) at com.commnav.sbh.framework.documentmanager.SBHDocument.loadComplex(SBHDocumen t.java:586) at com.commnav.sbh.framework.persist.PersistenceObject.load(PersistenceObject.j ava:208) at com.commnav.sbh.applications.documentmanager.FavoriteDocumentIteratorTag.doS tartTag(FavoriteDocumentIteratorTag.java:56) at apps.favorited_00025cuments._0002fapps_0002ffavoritedocuments_0002ffavorited ocumentspidget_0002ejspfavoritedocumentspidget_jsp_24._jspService(_0002fapps _0002ffavoritedocuments_0002ffavoritedocumentspidget_0002ejspfavoritedocumen tspidget_jsp_24.java:392) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.t
[JDBC] errors while getting large objects...
hello. my application uses large objects frequently...to render the main page, it might load anywhere from zero to 10 large objects - mostly images or documents. recently i started stress testing this page (making it always load many LOs) and i frequently encounter two different problems. 1. fastpath - autocommit is always false...i've verified this several times. my current workaround is to catch the fastpath error and resubmit the query...usually works on the second pass and rarely makes it to 4 passes (the current limit i have set). i have included a stack trace at the bottom of this message. does anyone have any ideas on this? i'm using 7.0.2 with the 7.0-1.2 jdbc driver. the occurences seem totally random...sometimes a page loads perfectly, sometimes i get three fastpath errors...sometimes the first load gets FP erros, sometimes the fifth page does. 2. hanging - i recently noticed that the processing sometimes (pretty frequently) hangs on the line of code that grabs the LO from the db...i've tried both: byte[] bytes = rs.getBytes(columnName); and InputStream is = rs.getBinaryStream(columnName); Same result for both. It hangs indefinitely. Similar to the fastpath - sometimes it happens, sometimes it doesn't...but it always happens within 5 screen loads of my stress test page. does anyone know if these problems were fixed in recent versions of postgresql? is anyone having similar problems? i greatly appreciate any help! thanks chris FastPath call returned ERROR: lo_tell: invalid large object descriptor (0) at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:141) at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:191) at org.postgresql.fastpath.Fastpath.getInteger(Fastpath.java:203) at org.postgresql.largeobject.LargeObject.tell(LargeObject.java:232) at org.postgresql.largeobject.LargeObject.size(LargeObject.java:247) at org.postgresql.jdbc2.ResultSet.getBytes(ResultSet.java:370) at org.postgresql.jdbc2.ResultSet.getBinaryStream(ResultSet.java:514) at org.postgresql.jdbc2.ResultSet.getBinaryStream(ResultSet.java:616) at com.commnav.sbh.framework.persist.JDBCEngine.loadResultSet(JDBCEngine.java:4 40) at com.commnav.sbh.framework.persist.JDBCEngine.load(JDBCEngine.java:284) at com.commnav.sbh.framework.persist.PersistenceObject.load(PersistenceObject.j ava:169) at com.commnav.sbh.framework.documentmanager.SBHDocument.loadComplex(SBHDocumen t.java:586) at com.commnav.sbh.framework.persist.PersistenceObject.load(PersistenceObject.j ava:208) at com.commnav.sbh.applications.documentmanager.FavoriteDocumentIteratorTag.doS tartTag(FavoriteDocumentIteratorTag.java:56) at apps.favorited_00025cuments._0002fapps_0002ffavoritedocuments_0002ffavorited ocumentspidget_0002ejspfavoritedocumentspidget_jsp_24._jspService(_0002fapps _0002ffavoritedocuments_0002ffavoritedocumentspidget_0002ejspfavoritedocumen tspidget_jsp_24.java:392) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.facade.RequestDispatcherImpl.include(RequestDispatcherImpl .java:345) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:414) at _0002fdesktop_0002ejspdesktop_jsp_130._jspService(_0002fdesktop_0002ejspdesk top_jsp_130.java:601) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl .java:194) at com.commnav.sbh.framework.navigation.handlers.NavigationHandlerImpl.execute( NavigationHandlerImpl.java:39) at com.commnav.sbh.f
RE: [JDBC] Large Objects
i have a different but related question - i OCCASIONALLY get a fastpath error. i'd guess that it shows up once in every hundred LO requests. i've verified that autocommit is set to false. the stack trace is shown here: FastPath call returned ERROR: lo_tell: invalid large object descriptor (0) at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:141) at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:191) at org.postgresql.fastpath.Fastpath.getInteger(Fastpath.java:203) at org.postgresql.largeobject.LargeObject.tell(LargeObject.java:232) at org.postgresql.largeobject.LargeObject.size(LargeObject.java:247) at org.postgresql.jdbc2.ResultSet.getBytes(ResultSet.java:370) at org.postgresql.jdbc2.ResultSet.getBytes(ResultSet.java:580) at (the rest is from my code)... any thoughts? thanks chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kovács Péter Sent: Monday, July 30, 2001 3:12 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Daniel Fisher; [EMAIL PROTECTED] Subject: RE: [JDBC] Large Objects This would be the standard way of inserting Large Objects. But last time I looked at it, it did not work with the jdbc implementation provided with pgsql. -Original Message- From: Nils O. Selåsdal [mailto:[EMAIL PROTECTED]] Sent: Friday, July 27, 2001 9:44 PM To: [EMAIL PROTECTED]; Daniel Fisher; [EMAIL PROTECTED] Subject: Re: [JDBC] Large Objects if you want to insert Large Objects, you need to use one of the setXXXStream of the statement, not setBytes. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
RE: [JDBC] null to zero?
hello. it seems that a null value in an integer (int4) column gets converted to zero at some point...is this accurate? i look in the db and see null (queried using IS NULL to make sure), but i call an rs.getObject(colName) and get a java.lang.Integer with a value of zero...is this in jdbc or java? an Integer can BE null, but it cannot have a value of null... didn't see anything in the archives... thanks chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
