I use a pattern in my services where I have methods that always return an Entity but it is up to that method whether to retrieve it from the database or create it newly. I call these methods methods. getOrCreate* An example. Users can add a to a . When a user enters a tag "JavaScript", I have a method in the called . In that method I lower-case the name and try to fetch tags from the data base with that homogenized name. In case it finds it, it retrieves it, otherwise it will create a new Tag Entity and retrieve that. Tag Post TagService getOrCreateTag(name: string) This can lead to a problem. When two requests to the backend occur at the exact same time, with the exact same string, two tags with the same name are inserted. (You think it is unlikely? Please read the note below the article!) What happens in slow-mo: Request A: asks whether that Tag exists Doesn't find it Decides to create it Request B meanwhile asks whether that Tag exists Doesn't find it Decides to create it Request A creates it Request B creates it You may prevent that easily by a unique key constraint. But you only shift the issue. Because then step 8. will just fail with an exception leaving the application crashing. One way to fix it, I will describe here implemented with TypeOrm. Pessimistic lock A lock of the database is always created during writing to the database. For example, step 7. and 8. both create a super short-living write lock. However, the issue was, that in step 2. and 5. respectively both requests couldn't find it and decided they are gonna write it to the database. already A pessimistic read lock is something you create . In TypeOrm you need the database connection for that. manually Repository: getOrCreateTag(name: string): <Tag> { .manager.transaction(
		(entityManager: EntityManager): <Tag> => { entityManager
				.createQueryBuilder(Tag, )
				.setLock( )                    
				.where({ name})                    
				.getOne()
				.then( (result) => { tag = result; ( === tag) {
						tag = Tag();
						tag.name = name; entityManager.save(tag);
					} tag;
				});
		}
	);
} async Promise return this Promise return "tag" "pessimistic_read" async let if undefined new return await return So, what it does is, it establishes a transaction (required for locks) and tries to fetch the tag. If not possible (tag is undefined) it is going to create one. So far so good. If you were running into the issue of two requests trying to create the same entity simultanously, you are now better. But, when you have concurrent requests you will now run into the issue of . Deadlocks "Deadlock found when trying to get lock; try restarting transaction." Deadlocks What happens now in slow-mo: Request A: creates a lock Request A: asks for whether that Tag exists Doesn't find it Decides to create it Request B meanwhile tries to create a lock will find the lock from request A will fail with message above Request A creates it The message means that have to restart the transaction. The same as locks are manual, the error catching and restarting is manual. you The Service getOrCreateTag(name: string): <Tag> { maxTries = ; currentTry = ,
            tryTransaction = ; tag = ; (tryTransaction) {
            currentTry++; {
                tag = .tagRepository.getOrCreateTag(
                    name, .createTagService
                );
            } (e) {} ( !== tag) {
                tryTransaction = ; } (currentTry >= maxTries) { ( );
            }
        } tag;
    } async Promise const 10 let 0 true let null while try await this this catch if null false // proceed, because everything is fine if throw new Error "Deadlock on getOrCreateTag found." return That's my solution. If you have a better one, let me know! Although it is very unlikely, that two users have the same tag entering at the time, it still can be. Imagine one user creates a tag but you happen to fire two backend requests in the frontend when he does that. One to store the tag, one to send a push notification to people who have subscribed to that tag. There is also other ways with optimistics locks, but I like the idea of letting the service simply "wait" for a split second. I have a monolithic app, so that works fine for me. Let me know, what you think about this.

Fetch

Super

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Solve Database Concurrency Issues with TypeOrm

Too Long; Didn't Read

Companies Mentioned

About Author

TOPICS

Languages

THIS ARTICLE WAS FEATURED IN...

Solve Database Concurrency Issues with TypeOrm

Too Long; Didn't Read

Companies Mentioned

About Author

TOPICS

Languages

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES