> If this is not possible, we have app-level locking to avoid conflicts.
app-level locking is a recipe for disaster if data matters and more than 1 process/user/client/etc can access your data. if the data doesn't matter then I guess you can do whatever you want.
web "developers" have a bad reputation for a reason. so many amateurs amongst web developers...
I will assume the last part is just a generic statement and is not directed towards me. You are a Java dev I presume?
As for app-level locking, I am talking about sacrificing performance, not safety. We just make sure that some piece of code runs exactly once. Since the need for this is very rare and the places are not performance critical, we can live with that. So no, we have no need for additional transactional guarantees on DB level.
> I will assume the last part is just a generic statement and is not directed towards me.
It's most definitely directed at you.
> You are a Java dev I presume?
C#/C++. Though I've worked with java before amongst others.
> As for app-level locking, I am talking about sacrificing performance, not safety.
You are sacrificing both. Only idiots truly depend on app-level locking.
> We just make sure that some piece of code runs exactly once.
Amateur hour...
> Since the need for this is very rare and the places are not performance critical, we can live with that. So no, we have no need for additional transactional guarantees on DB level.
So it's a useless pointless trivial application...
app-level locking is a recipe for disaster if data matters and more than 1 process/user/client/etc can access your data. if the data doesn't matter then I guess you can do whatever you want.
web "developers" have a bad reputation for a reason. so many amateurs amongst web developers...