I use a postgres database and I see the following error message:
could not serialize access due to read/write dependencies among transactions
DETAIL: Reason code: Canceled on identification as a pivot, during conflict out checking.
HINT: The transaction might succeed if retried.
The issue is that I have two transactions which are executed concurrently and they can influence each other.
This question is about understanding the error message itself, not about fixing the issue. I would love if somebody could walk me through it. Some questions I have:
What is the mentioned "identification"?
What is a pivot in this case?
What is "conflict out checking"?
Related
I spent a lot of time figuring out transactions on my otherwise well running ZIO+HTTP4S+Doobie-project.
How can I have proper [declarative] transaction management? Something like Spring #Transactional.
I read this very good post from-transactional-to-type-safe-reasonable-transactions, but ironically have exactly the alleged Spring challenge of getting confused how/where the transactions are precisely handled :)
Also tried tranzactio, even a entered a question under issues, where my PR (on my fork) seems to indicate individual transact calls are grouped in a single transaction?!
And here in bootzooka which is on the ZIO references list, I don't understand why the Resource is 'used' only once in main, and then transact is called around the logic. Well, I understand why it works, but I don't see any 'Strategy' or anything else letting me handle when an error in the first ZIO-effekt would let me control what happens to the second flatmapped effect...
Or how to assure there will be a single transaction happening for a HTTP4S-request.
Or an error handler, that got a #RequiresNew to actually store information about the error somewhere in the databse, even when all the previous logic is correctly rolled back.
I wouldn't mind helping others by writing up something about this, but I clearly have more to learn. About Doobie and ZLayers and so forth.
If there is something I am clearly missing here, please let me know :-)
I am getting this bizarre error when I try to run an UPDATE statement against a PostgreSQL database. I can't figure out what I even changed that is causing it, and I'm suspecting is a coincidental system error that is ancillary to something else I broke and fixed.
I'm literally at the "see if a reboot fixes it" point, but I want to know if anyone can tell me what this error means. I don't really understand sockets or transport interfaces very well.
Exception while reading from stream
Inner exception:
Unable to read data from the transport connection: Operation on non-blocking socket would block.
Inner exception: Operation on non-blocking socket would block
It has been many months since I had this problem. I actually DID solve it, but I forgot to add an answer. I'm attempting to add an answer now.
As I recall, the problem was simply an ordinary timeout problem. I had to increase one of the timeout settings (of which there are multiple) for PostgreSQL on my Connection parameters object.
EDIT: I should add that I was working with NpgSql at the time.
Is there any circumstance where an exception will not be thrown if an insert statement in a stored procedure fails?
I'm using catch-all style exception handling in my PostgreSQL stored procedures via EXCEPTION WHEN OTHERS THEN. I'm wondering if that's sufficient to catch all failed inserts.
That should cover it.
I quote the manual on Trapping Errors in PL/pgSQL:
The special condition name OTHERS matches every error type except
QUERY_CANCELED. (It is possible, but often unwise, to trap
QUERY_CANCELED by name.)
I am implementing some transactions using MongoDB. Since I have to implement my own rollback (and since the rollback could possibly fail), I would like to know what type of errors could prevent an update operation to succeed.
Here are the reasons I expect to meet:
Network issues (in which case we need to retry later),
The query didn't find the object I want to update (in which case the rollback should just ignore the update and continue with the other steps)
Is there any other reason that could prevent an update operation to succeed?
UPDATE:
This question is about knowing the different types of possible failure, so that the application's code can react to them accordingly.
I was looking for any suggestion or a good approach to handle messages between the data & application tier, what i mean with this is when using store procedures or even using direct SQL statements in the application, there should be a way the data tier notifies upper layers about statement/operation results in at least an organized way.
What i commonly use is two variables in every store procedure:
#code INT,
#message VARCHAR(1024)
I put the DML statements inside a TRY CATCH block and at the end of the try block, set both variables to certain status meaning everything went ok, as you might be thinking i do the opposite on the catch block, set both variables to some failure code if needed perform some error handling.
After the TRY CATCH block i return the result using a record:
SELECT #code AS code, #message AS message
These two variables are used in upper tiers for validation purposes as sending messages to the user, also for committing o rolling back transactions.
Perhaps i'm missing important features like RAISERROR or not cosidering better and more optimal and secure approaches.
I would appreciate your advices and good practices, not asking for cooks recipes there's no need, just the idea but if you decide to include examples they'd be more than welcome.
Thanks
The generally accepted approach for dealing with this is to have your sproc set a return values
and use raise error as has been previously suggested.
The key thing that I suspect you are missing is how to get this data back on the client side.
If you are in a .net environment, you can check for the return value as part of the ado.net code. The raise error messages can be captured by catching the SqlException object and iterating through the errors collection.
Alternatively, you could create and event handler and attach to the connection InfoMessage event. This would allow you to get the messages as they are generated from sql server instead of at the completion of the batch or stored procedure.
another option which I wouldn't recommend, would be to track all of the things you care about into a XML message and return that from the stored proc this gives you a little more structure then your free text field approach.
My experience has been to rely on the inherent workings of the procedure mechanisms. What I mean by this is that if a procedure is to fail, either the implicit raised error (if not using try/catch . . . simply CRUD stuff) or using the explicit RAISERROR. This means that if the code falls into the catch block and I want to notify the application of the error, I would re-raise the error with RAISERROR. In the past, I've have created a custom rethrow procedure so I can trap and log the error information. One could use the rethrow as an opportunity to throw a custom message/code that could be used to guide the application down a different decision path. If the calling application doesn't receive an error on execution, it's safe to assume that it succeeded - so explicit transaction committing can commence.
I've never attempted to write in my own communication mechanism for interaction between the app and the stored proc - the objects in the languages I interact with have events or mechanisms to detect the raised error from the procedure. It sounds to me like your approach doesn't necessarily require too much more code than standard error handling, but I do find it confusing as it seems to be a reinventing the wheel type of scenario.
I hope I've not misunderstood what you are doing, nor do I want to come off as critical; I do believe, however, you have this feedback mechanism available with the standard API and are probably making this too complicated. I would recommend reading up on RAISERROR and see if it's going to meet your needs (see the Using RAISERROR link for this at the bottom of the page as well).