Make temporary BLOBs have non-interlapping IDs and "invalid BLOB ID" error
message changed to actionable explanation
--------------------------------------------------------------------------------------------------------------------
Key: CORE-6193
URL: http://tracker.firebirdsql.org/browse/CORE-6193
Project: Firebird Core
Issue Type: Improvement
Components: Engine
Affects Versions: 3.0.4
Environment: any
Reporter: Arioch
Uplifted from http://tracker.firebirdsql.org/browse/CORE-6119
As of now the infamous "Invalid BLOB id" error means "s..t happened, hope
you're lucky to guess which specific one".
Reliable reproduction of bugs is not always possible.
And even in lucky cases when it is, it is not always possible to dispatch a
developer with full sources and full development environment to the customer
site.
Even in double-lucky case when it was possible, it is straining to narrow down
the case to simple demo exe and then demand someone from FB core team to debug
Firebird server w.r.t. that demo project.
So it would be nice if Firebird reported three different typical cases w.r.t.
temporary blobs:
- this blob is real but is not accessible from this transaction, isolation
violation between transactions A and B
- this blob likely did existed but does no more, too late
- this blob id is total lunacy, makes no any sense
Such an error, reported immediately by firebird to application, application to
user and user to vendor, will give much more information to app developers than
"s..t happened, you did not learn some of your lessons" reported now.
What prevents distinguishing and reporting different errors by engine is
overlapping of blob ids - "blob_id 1 at txA is not the same as temporary blob
with blob_id 1 at txB"
Making them non-overlapping would provide for better instant diagnostics and
for moving this class of errors from "Those are just things that routinely
happen with Firebird" into "clear cause is known and what code to fix in
application can be easily found" domain.
For two easy examples of de-overlapping, a temporary blob_id can be taken form
in-memory GENERATOR, or can be constructed as transaction id hash in high
digits with linear per-transaction counter in lower digits, counter overflows
would be quite OK in these cases, so no limits upon continuous uptime of
database connections would be imposed. Extra burden on the server, accounting
for all other works for BLOB transfers, should not be significant either.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
