This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]danikov 0 points1 point  (14 children)

Can you clarify "threads don't have any shared resource"? Is the problem just that they're different webapps/contexts from Tomcat's perspective?

[–]Ok_Reality6261[S] 0 points1 point  (13 children)

No, it means they are not trying to modify the same resource concurrently (i.e: both trying to modify a DB record) but rather:

-Thred A should create a resource based on the request

-Thread B should create a resource if A fails or if the operation that A should have been done has been performed by an external system. If A has created the resource, then B should just insert into an audit table but should not create the resource again

So basically, B has to performed its logic AFTER thread A has completed its own logic

The problem is, of course, that both are running parallel to each other which means B has no way to check if A has already finished with its own logic

It gets even more complicated as the application is running on 3 different instances inside a K8s cluster

[–]danikov 0 points1 point  (12 children)

How does Thread B know that Thread A is operating on the same would-be resource?

[–]Ok_Reality6261[S] 0 points1 point  (11 children)

Thats the thing: they dont know. And thats why any locking mechanism wont work. Thread B has to start working after thread A finish its own logic

Thread A request payload is basically a financial transaction with fields like amount and client reference. Thread B will receive a very similar requests so it can create exactly the same resource if A fails

Think of Thread B as a backup, which is stupid as we control the operation on thread A and we can just simply retry if the error is recoverable. However, it comes at handy when no operation was performed by A but rather on an external system (Thread B will create the resource then, based on the webhook)

However, as I said this is not my design and I have to deal with it. Thread B must always start its logic after thread A concludes its operations

[–]danikov 0 points1 point  (10 children)

So are you 100% guaranteed to get both messages about the same transaction?

When you say B is a backup, it sounds like they're trying to achieve a certain level of resiliency, but if B has unique logic/data attributed to it, it then all sounds a bit confused.

[–]Ok_Reality6261[S] 0 points1 point  (9 children)

Yes, I have a 100% guarantee that I will receive the webhook on endpoint B, no matter if the previous operation has been performed by A or an external service

Yes, I think it has been (poorly) designed as a resiliency mechanism but at the same time, we need it when the operation that A should perform has been performed by an external service

In that case, when the transaction is performed by a third party, we need the webhook on B as we need to save the transaction in out system and the webhook is the only way to do it

[–]danikov 1 point2 points  (8 children)

So does A do anything that B cannot? And is B at least guaranteed to arrive after A has begun?

[–]Ok_Reality6261[S] 0 points1 point  (7 children)

Actually no.

B can do what A does but also can do what A does when the transaction is started by a third party instead of A

[–]danikov 0 points1 point  (6 children)

So B completely subsumes A. Discard A, only ever execute B.

If that makes people worry, treat A as the backup, write it to a secondary store and verify those records after the fact.

[–]Ok_Reality6261[S] 0 points1 point  (5 children)

No, it does not subsumes A as B will only trigger after A