FR: zbox::Repo::ongoing_transaction

[vi]

ZboxFS seems to think in terms of transactions. There are transaction-related error cases in zbox::Error, there are limitations based on transactions (e.g. inability to write multiple files in parallel), but there is few things about transaction available in API.

If transactions are repository-wide (not file-scoped), I suggest to add something like fn ongoing_transaction(&self) -> Option<TransactionInfo>; in zbox::Repo, which should tell if a transaction is ongoing. Additional information like number of uncommitted bytes, affected file or datetime may be provided in TransactionInfo.

[burmecia]

Do you any special use cases for this request? Currently, all transactions are managed internally and they are not visible for application. I don't think there any necessity to expose it because transactions are tightly coupled with internal components and they are critical, app should not be able to control it.

Read-only visibility doesn't help either, app cannot do anything even it knows what transactions are on-going. The transaction information will be hard to interpret as it contains the internal objects information inside that transaction, such as Fnode, Store, Segment, Content and etc. Also, how the application call ongoing_transaction() will be a problem. They will have to create another thread to keep calling this method. This will add more complexity but for a narrow requirement, so I think that might not worth to implement.

[vi]

Fnode, Store, Segment, Content

This is no the information I expect to see about transaction.

Is pathname of a file being written and number of unfinished bytes available somewhere?

Initially TransactionInfo may be just empty struct, allowing ongoing_transaction only to check if a transaction exists or not.

---

They will have to create another thread to keep calling this method.

Main use case is to check if some transaction is ongoing before deciding to write a file.

Or is ZboxFS supposed to be only used one file at a time?

[vi]

Currently, all transactions are managed internally and they are not visible for application.

This abstraction becomes leaky as soon as user tries to do anything tricky with multiple files or multiple extends within a file.

Correct usage of zbox::File API requires to mind transactions, otherwise various errors (former panics) would be returned. There is transaction-related zbox::Errors. So one cannot say that transactions are completely an implementation detail.

[burmecia]

Fnode, Store, Segment, Content

This is no the information I expect to see about transaction.

Is pathname of a file being written and number of unfinished bytes available somewhere?

No, pathname is not in the transaction and there is no unfinished bytes. Thinking of writing as streaming, there is no way for ZboxFS to know if there any unfinished bytes.

Initially TransactionInfo may be just empty struct, allowing ongoing_transaction only to check if a transaction exists or not.

They will have to create another thread to keep calling this method.

Main use case is to check if some transaction is ongoing before deciding to write a file.

Or is ZboxFS supposed to be only used one file at a time?

ZboxFS supports multiple threads and you can operate on multiple files at same time but not on same file at same time. Thinking of each File as a RwLock, once a thread gain it in the transaction, no other threads can read or write on it until the transaction finished.

[burmecia]

Currently, all transactions are managed internally and they are not visible for application.

This abstraction becomes leaky as soon as user tries to do anything tricky with multiple files or multiple extends within a file.

Correct usage of zbox::File API requires to mind transactions, otherwise various errors (former panics) would be returned. There is transaction-related zbox::Errors. So one cannot say that transactions are completely an implementation detail.

That's what ZboxFS trys to achieve, to prevent all that 'tricky' things you can do in traditional file system. ZboxFS implements ACID transaction in the whole file system, because one of its goals is to store data reliably. App developer should bear in mind this, and I think that is good actually because transaction is a relief for developer as it grantees data integrity and persistence. App developers just need to think it differently other than from traditional perspective.