--- In Firebird-Java@yahoogroups.com, "Roman Rokytskyy"
<rrokytskyy@...> wrote:

>
> > One interesting thing is, i have never faced this kind of issue in
> > MySQL. The problem is with Firebird only.
>
> Did you use transactions with MySQL? What isolation level do you use

for

> Firebird?

Actually i dont use transaction for both the DBs.

>
> > Wont the Firebird engine lock the row before updation?
>
> No. Firebird has completely different scheme - it allows two concurrent
> transactions to update the same row without lock conflict, conflict

will be

> reported only on commit.
>

I dont understand the reason why it allows two different transactions
to do write operation and shout on commit.

> > Will he allow other thread also to access the same row for updation?
>
> The issue is not related to another thread, but to the way you

manage your

> transactions.
>
> If two concurrent transactions modify the same row, one of them must be
> rolled back in order to preserve the database consistency. If you don't
> really care about the data consistency - use auto-commit mode - each

update

> will be committed.
>

I dont use tranastion, so implicitly it should be auto-commited, isnt it?

> Roman
>