Category: Technical Articles

Technical articles, How-tos, guides, etc.

Jaybird undocumented tip : Is there any way to set socket timeouts?

Leave a comment

Is there any way to set socket timeouts?
Roman Rokytskyy answered :

-Yes, the property is called so_timeout and is directly passed when the socket is opened (see Socket.setSoTimeout documentation). You can append the property to the JDBC URL after question mark:

jdbc:firebirdsql:myhost/3050:/path/to/db.fdb?so_timeout=12345

– I have added this feature on request for some very special case. In general you don’t need this property, since the server is not supposed to crash and the network is not supposed to break as well, at least not for database applications. So, the solution is to solve the crash, not to add a workaround for it.

ps: soon it will be added to documentation

ANN: 2 new Trace API / FBTM screencasts: Parametrized query detection and enhanced error tracing

Leave a comment

Two new Trace API / FB TraceManager screencasts have been made available:

The first is discussing the usage of the Trace API to detect
parametrized query reusage, which allows to check if you are re-using prepared statements in e.g. batch processing scenarios or not.

The second demo discusses the new error/warning tracing capabilities to
be expected in Firebird 2.5.2(http://tracker.firebirdsql.org/browse/CORE-3539) and its integration/usage in FB TraceManager.

An ODBC driver for Firebird on MacOSX

Leave a comment

Via Paul Beach Blog

I was recently contacted by a Firebird user on MacOSX who was trying to get the Firebird ODBC driver to build on MacOSX. I thought I would try and step in to help.

For those of you who follow the CVS checkins for OdbcJdbc you might have noticed the addition of a number of a new directory in the Builds directory called Gcc.darwin containing a makefile, a readme and a .sh file to create a lipo’ed dylib. The driver sucessfully builds and passes some simple tests. Feel free to contact me for a copy of the dylib to test further.

The readme contains the following information

Dozens of new options for Firebird and .NET Framework

Hey!

If you have ever worked with Firebird or Interbase using the standard .NET provider for OLE DB (System.Data.OleDb), you will have likely encountered issues like this:

  • The necessity to add ALL parameters manually.
  • Even though the OLE DB provider supports parameter generation for commands, the .NET provider doesn’t use it, so you as the programmer must do that work on your own.
  • The lack of support for named parameters. Although they actually exist, using them in reality requires a whole set of complex manipulations (the steps needed to add a parameter to a collection, etc.).
  • The impossibility of using multiple DataReader objects at the same time (Multiple Active Result Sets).
  • No execution of SQL scripts which contain several SQL expressions per command.

This list of difficulties a .NET developer has to deal with is far from complete.

Now it’s all different in a fundamentally new ADO.NET Data Provider for OLE DB

IBProvider Team

Firebird driver

node-firebird vs node-firebird-libfbclient (pure JavaScript driver vs Firebird library wrapper)

Leave a comment

Denys Khanzhiyev (node-firebird-libfbclient creator) wrote on nodejs mailing list:
I must admit your lib is faster than mine (See the response from Henry (node-firebird creator) , it is the result of the firebird library mode of operation : synchronous vs asynchronous mode of nodejs)

Here is code
https://gist.github.com/2854642

here is ab results

node-firebird-libfbclient:

Concurrency Level: 5
Time taken for tests: 3.346934 seconds
Complete requests: 1000
Total transferred: 885000 bytes
HTML transferred: 821000 bytes
Requests per second: 298.78 [#/sec] (mean)
Time per request: 16.735 [ms] (mean)
Time per request: 3.347 [ms] (mean, across all concurrent requests)
Transfer rate: 258.15 [Kbytes/sec] received

node-firebird:

Concurrency Level: 5
Time taken for tests: 2.928723 seconds
Complete requests: 1000
Total transferred: 885000 bytes
HTML transferred: 821000 bytes
Requests per second: 341.45 [#/sec] (mean)
Time per request: 14.644 [ms] (mean)
Time per request: 2.929 [ms] (mean, across all concurrent requests)
Transfer rate: 295.01 [Kbytes/sec] received

A few words about the shared memory and files

Leave a comment

Even if running in the Classic (isolated process) mode, Firebird needs some data to be available to all the running server processes. There are four kinds of information that must be shared:

  • Lock table. It’s the vital part of the lock manager and its primary goal is to synchronize access to various resources that can be read or modified simultaneously.
  • Event table. Every time a posted event is committed, the server needs to find all the subscribers and redirect the event delivery to processes handling the appropriate user connections.
  • Monitoring snapshot. It keeps the latest known state of all the running worker processes and it gets updated once some user connection attempts to access the monitoring tables in a new transaction.
  • Trace configuration. It contains the information required for the worker processes to react on the currently active tracing events and log the appropriate notifications.

Continue reading at Dmitry Yemanov’s blog.

1 … 14 15 16 17 18 … 78