Syncronized vs. DB Transaction 1

[siberian]

I have a table that I need to make sure is updated in a transactionally clean fashion. Meaning only one client can update it at a time.

Usually I do this using SQL transactions and it works fine (other then the potential for long lived database locks in certain circumstances) but I am now thinking 'hey, wouldn't a syncronized routine do this just as well?'

So, the question is, whats the better approach from a performance standpoint? This is probably a religious question to a certain extent but I'm interested in opinions on it.

Tx

 

[stefanwagner]

Your transactions are managed from the database, and synchronization would be done from the java-app?

I would guess the transactions to be faster, because they are closer to the critical point.
And they work, if different clients are accessing the database.

Or is it a multi-tier application with synchronised code on the server as well?

It might depend on the database too - though in an enhenced environment every professional rdbms should have an elaborated transaction handling.

 

[siberian]

I am assuming DB is faster as well. The only thing syncronized would give me is the elimination of potentially locking conflicts. I've always used transactions, this just seemed like an alternative but I agree, the DB layer will probably be quicker.

Thanks!

 

[hologram]

>>I have a table that I need to make sure is updated in a transactionally clean fashion.
>>Meaning only one client can update it at a time.
This is not the same thing. Transactions are used so that updates to multiples files are done to ALL the files or NONE at all.
If you are talking about 1 table, then you don't need "hard"locking, unless you want to lock from the read until the update, but then you can get very long transactions. To prevent this you can use some form of "soft"locking.
- e.g. use an extra field in the database e.g. a counter that you increment with every update.
Suppose 2 users are accessing the same record. They will get the same countervalue. Before updating the record the counter field is read again from the database (and record locked) and compared with the value from the client. If the counter is still the same, the counter is incremented and the record updated. If the counter is not the same anymore, this means that someone else already did an update, and you can abort the operation or warn the user.

 

[siberian]

I prefer not to do locking in the logic side of things. I've been doing transactional stuff for years and just moved into the Java world and thought that syncronized might be another way to handle it but the consensus seems to be no.

Already gone back to my transactional ways