Missing transaction conflict between write and drop of objects

Detail name	Value
Changelog Number	5156
Type	Improvement
Status	Resolved
Fix Versions	Exasol 6.1.0
Resolution Date	2018-09-14

Currently in EXASolution the schema objects are not write-locked when dropped, but simply dropped. All schema objects exhibit this behavior. In some cases this leads to unexpected behaviors where transaction conflicts are expected, but none are happening and the affected object simply is not there anymore. An example for such a scenario is provided below:

Simple Example (autocommit off!):

CREATE SCHEMA s;
CREATE TABLE t AS SELECT 1 c;
COMMIT;

Timeline	Session 1	Session 2	Comment
1	SELECT * FROM t;		read lock on table T
2		SELECT * FROM t;	another read lock
3		DROP TABLE t;	table dropped, no write lock on it
4		COMMIT;	table is not there anymore
5	UPDATE t SET c=2;		Operating on old table version, no conflict
6	COMMIT;		also works, although a transaction conflict should be expected
7	SELECT * FROM t;		returns exception, table T doesn't exist any more

The same non-conflict behavior can be seen with create or replace.