Deadlocking in Concurrently Executed Nested Stored Procedures - sql-server

Question

I have a stored procedure that calls child stored procedures to parse JSON that is coming in from the client. The problem is that the JSON parsing mechanism is bottle-necking the application because it's doing it row-by-row. I had an idea to turn it into sort of a queue-ing structure where I could have x jobs running this same parent stored procedure and process through the records quicker. I created a proof of concept for this and it's periodically running into deadlocking issues that I am sort of at a loss as how to resolve. I'd first like to see if the way I'm handling the transactions and the general code is a reasonable method, and then I plan to approach my DBAs to see if they can help in actually resolving the deadlocks because I won't have the access in production to be able to do anything.
NOTE
Please ignore any syntax or spelling issues or lack of variables being declared. I cut out a lot of unnecessary code to keep this as simple as possible while trying to make sure the overarching strategy was still in place. Please consider this "pseudo-code". I realize that having the actual queries run in the child procs would be valuable in sorting out the cause, but I'm mainly interested in finding out if the way I'm using transactions in the nested procedures is correct, and if the transaction isolation level i'm using is right. Also, in the way of solutions, I'm wondering if programmatically re-processing the deadlocks is a valid work-around, or if I should be shooting for a different solution.
So this is the parent procedure:
CREATE PROCEDURE [dbo].[ParentProc]
#BatchSize int = 5
AS
BEGIN
SET NOCOUNT ON;
SET XACT_ABORT ON; --http://www.sommarskog.se/error_handling/Part1.html#jumpXACT_ABORT
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; --mandated by DBAs unless I provide good reason not to use it.
/*
I opted to use UPDLOCK and READPAST hints in this proc based on doing some research online to determine how best to handle a queue processing system, which is essentially what we're doing.
For reference: https://www.mssqltips.com/sqlservertip/1257/processing-data-queues-in-sql-server-with-readpast-and-updlock/
*/
BEGIN TRY
--this transaction just marks the records with a guid that this instance of the proc will be handling.
BEGIN TRANSACTION
DECLARE #ProcessID varchar(36) = (SELECT NEWID());
;with cte as (
SELECT TOP (#BatchSize) ProcessID, UpdateDate
FROM dbo.MainJSONTable
WHERE IsProcessed = 0
AND ProcessID IS NULL
AND ProcessingFailed = 0
ORDER BY CreateDate ASC
)
UPDATE cte WITH (UPDLOCK, READPAST)
SET ProcessID = #ProcessID,
UpdateDate = GETUTCDATE();
DECLARE #i bigint = 1;
SET #BatchSize = (SELECT COUNT(*) FROM dbo.MainJSONTable WHERE IsProcessed = 0 AND ProcessingFailed = 0 AND ProcessID = #ProcessID);
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
IF (##TRANCOUNT > 0)
BEGIN
ROLLBACK TRANSACTION;
RETURN;
END
END CATCH;
WHILE #i <= #BatchSize
BEGIN
BEGIN TRY
BEGIN TRANSACTION
SET #RowKey = (SELECT TOP 1 RowKey FROM dbo.MainJSONTable WHERE IsProcessed = 0 AND ProcessingFailed = 0 AND ProcessID = #ProcessID ORDER BY CreateDate ASC);
IF(#RowKey IS NULL)
BEGIN
RETURN;
END
BEGIN TRY
EXEC dbo.DoStuffInChildProc #RowKey;
END TRY
BEGIN CATCH
SET #msg = error_message();
RAISERROR (#msg, 16, 1);
END CATCH
UPDATE dbo.MainJSONTable
SET IsProcessed = 1
WHERE RowKey = #RowKey
AND ProcessID = #ProcessID;
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
IF (##TRANCOUNT > 0)
BEGIN
ROLLBACK TRANSACTION;
END
EXEC Logging.SetLogEntry ##PROCID, #msg;
UPDATE dbo.MainJSONTable
SET ProcessingFailed = 1
WHERE RowKey = #RowKey
AND ProcessID = #ProcessID;
END CATCH;
SET #i = #i + 1;
END
END
And here is an example of the child proc that is called. There are multiple child procs called, but this is how they are all handled:
CREATE PROCEDURE [dbo].[DoStuffInChildProc]
#RowKey bigint
AS
BEGIN
SET NOCOUNT ON;
SET XACT_ABORT ON; --http://www.sommarskog.se/error_handling/Part1.html#jumpXACT_ABORT
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; --mandated by DBAs unless I provide good reason not to use it.
BEGIN TRY
--before this i get some dynamic sql ready.
EXEC sp_executesql #FinalSQL;
END TRY
BEGIN CATCH
IF ##trancount > 0 ROLLBACK TRANSACTION
DECLARE #msg NVARCHAR(200) = CONCAT('[dbo].[DoStuffInChildProc] generated an error while processing RowKey ', #RowKey);
EXEC Logging.SetLogEntry ##PROCID, #msg, #FinalSQL;
RAISERROR(#msg, 16, 1);
RETURN 1;
END CATCH;
END
The error in my log is for the parent procedure:
Transaction (Process ID 60) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
UPDATE
This is the table create statement, and I just realized there currently aren't any indexes on the table other than it's clustered on the primary key. All of the child procs are selecting the Result field which contains the JSON to be parsed. Should I be committing the child transactions as soon as they're finished, or just bubbling up to the parent proc?
CREATE TABLE dbo.MainJSONTable (
TableID bigint IDENTITY(1,1) NOT NULL,
ParentTableFK bigint NULL,
Result nvarchar(MAX),
IsProcessed bit NOT NULL,
ProcessingFailed big NOT NULL
ProcessID
)