Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Free external tables [CORE961] #1364

Closed
firebird-automations opened this issue Oct 23, 2006 · 15 comments
Closed

Free external tables [CORE961] #1364

firebird-automations opened this issue Oct 23, 2006 · 15 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Maxim (paratruper)

Relate to CORE132
Is related to QA58
Jira_subtask_outward CORE1647

Votes: 1

Firebird don't free external tables (files) after end transaction, where they was uses.
I need features, where firebird unlock external tables (files) after commit transaction which they was uses.
Thank you.

Commits: b3dcfed

@firebird-automations
Copy link
Collaborator Author

Modified by: Maxim (paratruper)

description: Firebird don't free external tables (files) after end transaction, where they was uses.
I need features, where firebird unlock external tables (files) after commit transaction witch they was uses.
Thank you.

=>

Firebird don't free external tables (files) after end transaction, where they was uses.
I need features, where firebird unlock external tables (files) after commit transaction which they was uses.
Thank you.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Vlad Horsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Fergus McDonald (fergusm)

This would make external tables far more useful, particularly if you're using them as a way to import external data.. for example, if you want some other process ont he server to create the file, and then have firebird access it via external table.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

Link: This issue relate to CORE132 [ CORE132 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

External table's file will be closed when relation is not used by the engine.
I.e. when all requests referencing this relation are freed

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.1 [ 10041 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

issuetype: Task [ 3 ] => Improvement [ 4 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Fix Version: 2.1 Beta 1 [ 10141 ]

Fix Version: 2.1.0 [ 10041 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is related to QA58 [ QA58 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Robert Gilland (robert.gilland_basx.com.au)

The external file is not being released.

steps to reproduce

1. Create External file
2. Create External table
3. create stored procedure to import the external table
4. run stored procedure ( wait till finished )
5. call Windows.Deletefile to the original external file

result windows error

The process cannot access the file because it is being used by another process

This task should mean when the external table is not being accessed there should be no file handle open on it. But
firebird still has a file handle on it.

Using Firebird 2.1 beta to test with

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Read coment above - "External table's file will be closed when relation is not used by the engine". And this is worked as written.
But procedure's request is not closed by the engine until procedure is in metadata cache.
We'll look at it in v2.5

And don't post the same comment in two tickets, please

@firebird-automations
Copy link
Collaborator Author

Commented by: Robert Gilland (robert.gilland_basx.com.au)

No one is using the external file because the stored procedure is finished it's task.
Not sure what you mean by metadata cache.

So then how can I delete the original external file?
Currently I have a work around thankfully I can truncate the external file and rebuild upon it.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

When you execute procedure first time engine reads it metadata from disk, compiles BLR into execution tree and remembers (cached) this info as compiled request. This compiled request remains in metadata cache until shutdown or drop\alter procedure. Therefore this request didn't release its interest in used resources (tables, indexes, procedures etc) and engine don't closed external table's file.

If you would work with external tables not via procedures, engine (since v2.1) will close external table's file as soon as all interested requests are closed by your application.

So as workaround you may use EXECUTE BLOCK instead of stored procedures for work with external tables in v2.1.
Not perfect, i know, but we can't improve this in v2.1 as it is at near release candidate state.

If you did this report at beta1 stage i sure we would fix it at that time.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 11266 ] => Firebird [ 15359 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants