Issue Details (XML | Word | Printable)

Key: CORE-2475
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Tim Barber
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Firebird Core

External table data not visible to other sessions in Classic

Created: 27/May/09 05:17 AM   Updated: 26/Apr/13 08:00 AM
Component/s: Engine
Affects Version/s: 2.1.2
Fix Version/s: 2.5 Beta 2, 2.1.3

Time Tracking:
Not Specified

Environment:
Windows XP
Firebird 2.1.2 Classic install
Forced Writes for the DB was on.
Issue Links:
Relate
 

Planning Status: Unspecified


 Description  « Hide
In 2.1.2 SuperServer, any data written to external tables are visible to other sessions.
However in Classic, this data is not visible. It seems to be cached and written to file eventually, when this happens it becomes visible.

Super Server behaviour:
We created a new external table.
In session A we inserted data with no commit. The external table file was showing 0 size.
Started session B and selected data from the external table. The data was returned, and this triggered the a file flush and the external table file now shows the data (viewing the file in Windows).
Committed session A and data visibility still behaves correctly.

Classic behaviour:
We created a new external table.
In session A we inserted data with no commit. The external table file was showing 0 size.
Started session B and selected data from the external table. No data was retuned and the external table file is still 0 size.
Select from external table using session A or Commit or disconnect session A and the data is flushed to the file. It is now visible from session B.


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 27/May/09 06:34 PM
An external table feature was not intended for inter-session data transfer, but rather simple text import/export functionality.

IMHO, this is as-designed functionality.

Tim Barber added a comment - 28/May/09 02:27 AM
I agree that import/export would be one of the main uses of external tables, but they are defined as being like tables with certain restrictions - inter-session data visibility not being one of them.

We started development of a project that utilises external tables using Firebird 2.0 and have started testing against Firebird 2.1.2 where we discovered this issue - Firebird 2.0 behaves as expected (besides the locking problems that is!).

Looks like other Firebird users expect this behaviour:
http://www.volny.cz/iprenosil/interbase/ip_ib_isc4.htm
Implementation like this would not work with out inter-session visibility.

Vlad Khorsun added a comment - 30/May/09 12:18 PM
Before v2.1 external table's IO was performed without caching and thus was very slow.
In v2.1 caching was turned on but it introduced side effect reported here. There is no issue in SS as written data flushed on first read after write.
But in CS we have an issue.

Vlad Khorsun added a comment - 05/Jun/09 09:37 AM
Backported into 2.1.3

Pavel Cisar added a comment - 26/Apr/13 08:00 AM
Test added.