Have you checked whether the isolation level is set differently? I'm not sure but the default isolation level is 0 (which allows dirty reads, say against a freshly inserted row) whereas the JDBC driver might use isolation level 1 by default, meaning it would possibly be blocked during such a read...

As Breck has stated, please show us what the INSERT and the according trigger and procedure really do.

Regarding the isolation level. Should it be changed on the client side or should it be set at the beginning of the procedure?

We'll force the isolation level in the JDBC driver to 0 and see what happens

It doesn't matter what you set the database-level isolation level to, if every time a connection starts it is sent through the nightmare called sp_tsql_environment which changes the connection-level isolation level by executing SET TEMPORARY OPTION isolation_level='1';

One solution is to add code to change the connection-level isolation level after login.

Or (much better)... you could take control by coding your own login_procedure that does NOT call sp_tsql_environment.

Here is the full story...

The default login_procedure option is this: SET OPTION PUBLIC.login_procedure = 'sp_login_environment';

That forces all your connections to call this, which in turn sends TDS (i.e., jConnect and Open Client) connections to sp_tsql_environment:

ALTER PROCEDURE "dbo"."sp_login_environment"()
begin
  if "connection_property"('CommProtocol') = 'TDS' then
    call "dbo"."sp_tsql_environment"()
  end if
end

This truly evil procedure tries to make SQL Anywhere behave like a Sybase SQL Server database from 1995:

ALTER PROCEDURE "dbo"."sp_tsql_environment"()
begin
  if "db_property"('IQStore') = 'Off' then
    -- SQL Anywhere datastore
    set temporary option "close_on_endtrans" = 'OFF'
  end if;
  set temporary option "ansinull" = 'OFF';
  set temporary option "tsql_variables" = 'ON';
  set temporary option "ansi_blanks" = 'ON';
  set temporary option "chained" = 'OFF';
  set temporary option "quoted_identifier" = 'OFF';
  set temporary option "allow_nulls_by_default" = 'OFF';
  set temporary option "on_tsql_error" = 'CONTINUE';
  set temporary option "isolation_level" = '1';
  set temporary option "date_format" = 'YYYY-MM-DD';
  set temporary option "timestamp_format" = 'YYYY-MM-DD HH:NN:SS.SSS';
  set temporary option "time_format" = 'HH:NN:SS.SSS';
  set temporary option "date_order" = 'MDY';
  set temporary option "escape_character" = 'OFF'
end

If you NEVER want that to happen, try this:

SET OPTION PUBLIC.LOGIN_PROCEDURE = '';

Or substitute your own code:

CREATE PROCEDURE DBA.my_login_procedure()
BEGIN
  -- do whatever you want
END;

SET OPTION PUBLIC.LOGIN_PROCEDURE = 'DBA.my_login_procedure';

Be sure to let us know if changing the isolation level to 0 stops the deadlocks.

As stated above, you could also try to use a table hint within the query that tries to read freshly inserted rows... If only one or a few tables are involved, that may be easier than altering the login procedure...