1

I have a Web app running on Apache Tomcat 6, using ZK, Hibernate and Jaybird JDBC for accessing a Firebird database. For some unknown reason, after a not yet mapped operation in the app that performs a dynamic SQL, it crashes with the following exception:

ERROR: org.springframework.transaction.TransactionSystemException: Could not roll back JPA transaction; nested exception is javax.persistence.PersistenceException: unexpected error when rollbacking javax.persistence.PersistenceException: unexpected error when rollbacking org.hibernate.TransactionException: JDBC rollback failed [SQL: 335544726, HY000] org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544726. Error reading data from the connection.

Reason: Error reading data from the connection. ...

Then, any operation performed by the user after it causes the following error:

ERROR: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not execute query org.hibernate.exception.GenericJDBCException: could not execute query [SQL: 335544721, HY000] org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544721. Unable to complete network request to host "". Reason: Unable to complete network request to host "".

And the system crashes down, like if it had lost the connection with the database.

Has anyone experienced it before?

Erick Sperandio
  • 198
  • 2
  • 14

5 Answers5

5

After some research and tests, I've got to understand what was happening.

The problem was happening when a user was performing a specific search in the app using a string with size greater than the target table field's size. So, when the system executed the HQL query with the string input as a parameter, the system crashed down - like when comparing a string with length 20 to a varchar(18) field.

The solution was simple: limit the size of the input string in the search field.

Hope this helps anyone in the future.

Erick Sperandio
  • 198
  • 2
  • 14
0

You're not being able to connect to the database. The code 335544721 is a result of an active denial of access, that may be caused by a variety of elements, such as bad login, firewall rules avoiding the connection or antivirus blockage

renke
  • 1,180
  • 2
  • 12
  • 27
  • 1
    Jaybird will throw this error for `IOException`s while reading from the connection. This is not necessarily an active denial of access. It could also be a broken connections or invalid operations on the network socket for the current state of that socket. – Mark Rotteveel Feb 25 '14 at 19:43
  • The problem is not related to active denial of access. As I stated before, the app is running until a certain operation is performed by the user. From this momment on, the system starts to show this error. – Erick Sperandio Mar 04 '14 at 18:23
0

I also had a similar problem, in my case it happened because I used LIKE condition and together with two "%" signs the length of parameter exceeded the length of the field.

So, for example, if I have a table:

create table TEST (name varchar(5) default '' not null);

When I try to search by the following condition and have parameter param1 = '%name1%' (as you see 'name1' is valid for varchar(5) field):

select * from TEST where name like :param1;

I have the same error in hibernate, and after this error I cannot execute any queries, probably because hibernate session is broken.

Hope it may help somebody.

Maxim Votyakov
  • 714
  • 5
  • 10
0

I solved it by restarting the FirebirdGuardianService on the server.

Stimpson Cat
  • 1,444
  • 19
  • 44
0

you can solve this discarding the connection and not reusing it.

the problem happen when you use the same connection sometimes and the driver/firebird stop producing the correct answer.

In my experience, if you use the same connection to run more than 500 times (in 500 queryes) even after commiting transaction and keep the transaction open you are a strong candidate to get this problem.

so what you can do to create a counter and after it gets bigger than 500 close the current transaction and create a new one.

you have to pay attention when it has DML commands in the current transactions [e.g. update, delete]. If you close the transaction with those commands you have be careful with the integrity of the whole operation.