> Actually i dont use transaction for both the DBs.

Ok.

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

This is called MVCC - multi-version concurrency control, MySQL has it only
for INNODB tables (which support transactions). The update creates new
version of the record, which is visible only for the current transaction.
This allows other transactions to read old version of the record, which
increases throughput. When transaction is committed, engine checks whether
the new version is the next version, or some concurrent transaction has
updated the same record and already committed.

There is a plenty of information on this topic, why it is better, how it
works and what might be the issues.

But anyway, it does not apply to you, since you do not use transactions at
all.

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

Yes.

Ok. Now, most likely your situation is the following. Firebird does not
support auto-commit at all, and JDBC driver emulates it by starting a
transaction before executing the statement, and committing right after the
execution. For me this is the only reason why it happens - it is not related
to locking the record on reading, since you do not use transactions.

So I assume that you update data very intensively, and MySQL executed them
sequentially. Firebird tries to execute them in parallel, but then some
updates conflict.

So, the easiest thing for you is to execute failed update again. But again,
I assumed simple situation, your system might look differently...

Roman