Ivan,
this really sounds as if the transaction in which you delete the data sets
is not closed: If you use the same conection to re-read the data (with
Torque), the datasets are gone, but if you use another connections, the
datasets are still there because the transaction where the delete occurred
is not yet committed.
Maybe Torque 3.0 had a problem with transaction handling. Back then,
transactions were not supported by most open source databases, so errors
might not have been noticed.
I can see two options for you:
- Upgrade to a newer Torque version
- debug the code yourself and find out why the transaction si not closed.
Hope that helps,
Thomas
On Fri, 17 Nov 2006, Ivan Ivankovic wrote:
Hi Michel,
I already tried to wrap deletion in transaction and it didn't work but the
thing you're saying about table locks might be the answer. Could you explain
me hoe to check those locks?
Program flow where I first encountered this problem goes like this:
1. User is provided with list of database records on web page. Every one of
them has delete button beside. List is obtained with JDBC query.
2. After clicking delete in Struts action deletion is done with Torque, and
user is forwarded back to list page.
3. JDBC query is performed in order to redisplay list. And guess what :)
data I've just deleted is still there. It is in database when I check with
Squirrel DB browser as well.
Solution 1: When I rewrote list action to use Torque instead of JDBC data is
gone for good. I checked it with DB Browser and it also isn't here.
Solution 2: When I delete data with Torque I ask for it again with Torque
with retrieveByPK(key). I caught exception thrown because Torque didn't find
data and forward to list page. List uses JDBC but data is now gone.
That made me think that actually invalidation is performed instead of
deletion; and real deletion happens after data is first read. With Torque of
course.
Can you help me with those locks maybe that the will help.
Thanks,
Ivanko
-----Original Message-----
From: Michael Manske [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 16, 2006 8:33 PM
To: Apache Torque Users List
Subject: Re: Cache problem after delete
Hi Ivan,
> I use Torque 3.0 with Postgres and have following problem:
3.0 is a little bit out-dated, isn't it? ;-)
> After deleting some concrete object with usual
> ClassNamePeer.doDelete(objectToDelete), I can still see it in database
when
> querying for that objects information with plain JDBC.
That should not happen, as long as you don't use
Connection con = Transaction.begin("myDB");
ClassNamePeer.doDelete(objectToDelete, con);
and did not commit the transaction via
Transaction.commit(con);
> I suppose that Torque has some delayed deletion mechanism
No, Torque has not such a mechanism - the record should be deleted
immediately as long as no other process holds a lock on the record or table.
Checking for locks on the table could be a good idea. We were facing
a similiar behaviour with Oracle some time ago:
While using the doDelete() and doUpdate() methods, sometimes it took long
time
until Oracle told the client that it has detected a lock. Perhaps you are
facing a similiar situation with Postgres?
cheers
Michael
Ivan Ivankovic schrieb:
Hi,
I worked with Torque only for past 2 weeks, and I found it very useful.
I use Torque 3.0 with Postgres and have following problem:
After deleting some concrete object with usual
ClassNamePeer.doDelete(objectToDelete), I can still see it in database
when
querying for that objects information with plain JDBC.
When I use any of Torque query methods, via Criteria or retrieveByPK(key),
object seems to be erased, but some parts of application I am working on
use
JDBC so I can't rewrite all code to use Torque
BasePeer.executeQuery(queryString). Database data for this object can also
be seen from Squirrel JDBC browser which of course uses plain JDBC.
I suppose that Torque has some delayed deletion mechanism and I need some
way to make him do the actual deletion completely from database. Is there
some kind of "flush" to achieve this?
Regards,
Ivanko
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.0.409 / Virus Database: 268.14.6/535 - Release Date: 15.11.2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.6/535 - Release Date: 11/15/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
