[Tm4j-developers] [ tm4j-Bugs-973979 ] Exception when creating two topics with the same base name

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Bugs item #973979, was opened at 2004-06-16 17:08
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=973979&group_id=27895

Category: Hibernate Impl
Group: TM4J 0.9.6
>Status: Pending
>Resolution: Rejected
Priority: 7
Submitted By: Andy Peel (atpeel)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Exception when creating two topics with the same base name

Initial Comment:
If I create two topics with the same base name, I get
this exception:

Message:
testUpdateTopic_SameBaseName(test.client.TestTopicDelegate):
Source exception thrown:
org.tm4j.topicmap.TopicMapRuntimeException: 
Cause: java.sql.SQLException: ERROR:  syntax error at
or near "topic_types" at character 15
Cause:ERROR:  syntax error at or near "topic_types" at
character 15

The problem seems to be inside
org.tm4j.topicmap.hibernate.TopicImpl.replaceTopicReference()
where the SQL query generated includes the fragment
"update ignore". The ignore keyword only seems to work
on BDB/MySQl, whereas I'm using PostgreSQL.

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-27 15:18

Message:
Logged In: YES 
user_id=176992

The flush is actually superfluous now. Under a previous
version of Hibernate, the default Hibernate flushing code
was not flushing updates before doing a query. This seems to
be fixed with the current version of Hibernate, so those
flushes could probably be removed.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-09-15 15:05

Message:
Logged In: YES 
user_id=1064816

It turns out that the problem was that our
HibernateSpoofTransactionManager was swallowing the explicit
flush calls made by TM4J. We've also tested this for
transaction isolation correctness and it's fine.

Can you shed some light on why the flush is needed?

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-14 13:37

Message:
Logged In: YES 
user_id=176992

I have successfully replicated this problem with the early
commit. Even when unecessary session.flush() calls are
removed, a commit still occurs before any query. If you
write code like:
Topic t = tm.createTopic("topic1);
BaseName bn = tm.createName("bn1");

The row for the Topic gets committed just before the system
checks the id "bn1" is not a duplicate ID. It looks like the
Hibernate code needs to be reviewed for transaction isolation.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-09-13 16:13

Message:
Logged In: YES 
user_id=1064816

Time passes...

OK, having reopened this at our end to try and get to the
bottom of it, it seems that the test I wrote to test Kal's
fix had a bug in it...
The bug in the test has now been fixed and we can reproduce
the problem that I got before. The exception I sent Kal in a
private email was as follows:

Message:
testUpdateTopicSameBaseName(test.client.TestTopicDelegate):
Source exception thrown:
org.tm4j.topicmap.TopicMapRuntimeException: 
Cause: java.sql.SQLException: ERROR:  update or delete on
"tmobjects" violates foreign key constraint
"fkce45afe9c6f0e22b" on "topic_sips"
Cause:ERROR:  update or delete on "tmobjects" violates
foreign key constraint "fkce45afe9c6f0e22b" on "topic_sips"

We have tried running the code *without* our custom
transaction manager code, and calling
provider.openTransaction() instead. Our test then passes
fine and I can create two topics with the same base name
that are then merged inside TM4J. Our custom transaction
provider mechanism basically subclasses Hibernate's
SessionFactory and Session classes with spoof versions that
are wired into a simple transaction manager that forces the
use of a single transaction per thread (analagous to
Hibernate's Session-In-View pattern).

This is different to the way the transaction opened by
calling provider.openTransaction() works. By putting some
breakpoints into our test we found that every time we create
a topic and set its base name, the transaction's commit
method is called 4 times - you can actually see the data
being inserted into the tmobjects table as you step through
the code. This really needs to be done atomically, in a
single transaction.

Of course if you don't use a custom transaction provider and
you don't call provider.openTransaction() then TM4J creates
and commits a transaction for each operation is performs
internally.

So it looks like it's the fact that the TM4J-managed
transaction is being committed too early is preventing the
topic_sips foreign key violation from happening.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-06-22 16:59

Message:
Logged In: YES 
user_id=1064816

This works fine when I test it with stand-alone code,
although I still have problems when I run within my code base. 

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-18 18:28

Message:
Logged In: YES 
user_id=176992

Fixed error in the static merging code that caused this
exception. Waiting on confirmation that the fix actually
works on PostgreSQL...

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-17 20:13

Message:
Logged In: YES 
user_id=176992

Sorry, I misunderstood the problem. I need to take a closer
look at that SQL update. I used SQL directly for this
operation for perfomance, but my simple update statement can
violate key constraints (especially when merging on names or
subject indicators I think). I *think* that there must be a
way to do what I want without temporarily violating key
constraints.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-06-17 10:11

Message:
Logged In: YES 
user_id=1064816

Hi Kal,

I'm pretty sure that won't make a difference - the SQL query
in TopicImpl includes the IGNORE keyword, and as far as I
can make out, that only works with BDB/MySQL. I even tried
the query directly using psql, but to no avail.

Andy.

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-16 19:10

Message:
Logged In: YES 
user_id=176992

I wonder if this is a Hibernate problem. There was a new
Hibernate release on June 1st (2.1.4) - perhaps it is worth
giving that a spin to see if the Postgres problem got fixed ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=973979&group_id=27895