Thanks Roman, for explaining all these. Let me see what works out for me.

FYI: This simple piece of code, which doesnt have any transaction,
generates the same exception.


import java.sql.*;

public class FirebirdIssueTest
{
private static int j =0;

public static void main(String arg[]) throws Exception
{
j = Integer.parseInt(arg[0]);
String url =
"jdbc:firebirdsql:localhost/3050:/opt/interbase/bin/WebNmsDB";
try
{
Class.forName("org.firebirdsql.jdbc.FBDriver");
}
catch (ClassNotFoundException cnfex)
{
System.err.println("Not found the class.");
}
Connection c = DriverManager.getConnection(url, "sysdba",
"masterkey");
Connection c1 = DriverManager.getConnection(url, "sysdba",
"masterkey");
final PreparedStatement ps = c.prepareStatement("update
TestTable set details = ? where ID = 153");
final PreparedStatement ps1 = c1.prepareStatement("update
TestTable set Status = ? where ID = 153");
for(int i = 0 ; i < 2 ; i++)
{
Thread t = new Thread(new Runnable()
{
public void run()
{
if(j % 2 == 0)
{
System.err.println("Going to
execute the statement >>>"+ (++j));
execute(ps, "Thread"+j);
}
else
{
System.err.println("Going to
execute the statement >>>"+ (++j));
execute(ps1, "Thread"+j);
}
}
});
t.start();
}
}

public static void execute(PreparedStatement ps, String val)
{
try
{
ps.setString(1, val);
ps.execute();
}catch(SQLException sqle)
{
System.err.println("Exception >>>"+ val);
sqle.printStackTrace();
}
}
}







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

>
> > 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
>