View Full Version : Re: Slimserver footprint, time and space,andanarchitectural suggestion

John A. Tamplin
2005-06-06, 12:09
On Mon, 6 Jun 2005, Jeff Coffler wrote:

> Okay, you're making more sense here. Phew! What you're discussing (in your
> latest message) is a PERL limitation, not a database limitation.

Since Slimserver is written in perl, that seems relevant.

> Berkeley DB (which is a database, by the way - just a BTREE database - and
> it does have a PERL interface to access it)

What I mean is that DB provides normal ISAM-like services to a single
table. If you want to do a join, you have to do that yourself looking at
multiple tables. If you want to maintain multiple indices to a table, you
have to build it yourself. So, I consider it a rather low-level indexed
storage mechanism and not a true database, with the distinction being that
a database knows about inter-table relationships, schema, data types, and
can operate on multiple tables and multiple indices in individual
operations. (Yes, I know the more recent versions provide limited
capabilities for joins and secondary indices, but this is still not close
to the functionality of a relational database).

See http://www.sleepycat.com/docs/ref/intro/dbisnot.html

> and Oracle both have no problems with many many threads in one process.
> These do not require a connection per thread model.

So I can open a connection to the database and then have multiple threads
simultaneously execute queries/etc on that single connection and not doing
any sort of synchronization in my code? Does it simply maintain a mutex
per connection? Can you bind parameters in one thread and then execute
the select in another thread? Etc... there are a lot of issues that come
about when trying to share database connections in a multithreaded
application. I am not saying it can't be done, just that it is not
trivial and specifically not very portable between different databases.

It has been many years since I wrote native PRO*C code -- lately all my
experience with Oracle code has been via perl.

> The PERL limitations are *PERL* issues, not database issues.

Ok, but since we were discussing making Slimserver multithreaded (or
otherwise partitioning it into multiple threads of control) and it is
written in perl and accesses the database, limitations of any piece
are relevant to the discussion.

John A. Tamplin jat (AT) jaet (DOT) org
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723