[Opendnssec-develop] Minutes of 2012-08-07

[Jerry Lundström]

Hi all,

These are my comments on yesterday meeting:

2.

- Sion explains that not all (older) SQLite installs supported
transactional behaviour.  So we've surrounded it with another lock.
This may run into a race condition in some situations.  Whether an
install is transactional is not easily deduced by looking at it, or
querying parameters.

Actually looks like transactions has been around in SQLite since 2001
/ v2.0 so all SQLite installations today do support transactional
behavior.

Just because you have transaction does not mean you can't get dead
locks, its more the other way around that because of transaction you
do get dead locks. This is more a matter of database design, SQL usage
and the type of transaction locking the database engine does
(database/table/row/column etc).

- Matthijs adds thatit could help to test it if it is installation-dependent.

Many of the problems we have with SQLite is very installation and OS
depended. Beside the issue with locks there is the problem with the
extreme slow read/write that some have reported, for example on a
FreeBSD 8+ installation on very modern hardware Enforcer took 45min to
do a run (cycle) on 870 zones to check if there was anything to do.

I do not think we should really spend time to track these issues down
since there are so many things that can affect performance but we
should make MySQL the primary database engine since we know it works
better.

- ACTION POINT Jerry & Sion: See if this works.

See if what works? Locking?

- Rick finds the SQLite FAQ on http://www.sqlite.org/faq.html#q6and
sees that sqlite3_threadsafe() could be called during configure to
determine if the installation is suitable for OpenDNSSEC; if not, the
user can be asked to install their own version and supply a path to
use from OpenDNSSEC.  This will enable us to remove our (problematic)
locking issues.

Thread safety does not have anything to do with multiple programs
accessing the database. Checking thread safety is more a matter for
2.0 and the multi threaded Enforcer. (more on SQLite threads
http://www.sqlite.org/threadsafe.html)

The locking we have outside the database today is to hinder other
programs to access the database while we work at it. That kind of
access should be possible with the transactional behavior that SQLite
has.

- Yuri wonders if this issue will influence 2.0 releases, and so if
this is going to continue being a problem.

No it won't, we just add a little check for thread safety :)

5.

- Sion adds some concern about duplicating code, as the broad setup of
each test is often the same.

This is something me and Sara has discussed also and she raised the
same concern.

My point for having it like this is that it may look like every test
setup the same way today and making that a mandatory way of setting up
will break tests in the future that can't be setup like that.

But there are other way of setting simple code and that is by adding
more functions where the code is the same. Me and Sara talked about
adding ods_start_enforcer instead of the two lines that are there now
and things like that. We could add a ods_standard_setup that mimics
the setup done is more tests today without enforcing a setup routine.

6.

1.4.0-alpha3 - I am ready to tag/ball/release when you say so Rick!

/Jerry