SqueakDBX - Architecture and desing
Last updated at 11:58 pm UTC on 30 March 2009
Understanding OpenDBX architecture
It is very important you understand which components are present in this architecture and how they are related. To make this easy, suppose we have a server called 'Server1' where your specific application resides and a server called 'Server2', where the database manager runs, suppose, it's oracle.
This is the component diagram of that:
Now, which is each component?
Component 1: This is just your application that uses OpenDBX. This application sees OpenDBX like any other C library. Depending on the platform it could be a .dll, .so, etc.
Component 2: It's OpenDBX library core. OpenDBX's architecture says there is an openDBX core which has the API, and then it has an OpenDBX backend for each RDBMS it supports. So, this component, will delegate in the appropriate backend (oracle in this case). This is why extending OpenDBX to another backend is so simple.
Component 3: It's the particular OpenDBX backend for a database. There will be as many as database engines are supported. This component is the one that maps de OpenDBX API to the particular engine.
Component 2 and Component 3 are part of OpenDBX. You can see Component 2 in /lib and Components 3 in /backends in the .tar.gz of OpenDBX.
Component 4: This is the library (written in c) your database vendor gives you so that you can talk to it. Sometimes you have to install the client package of the database (not the server).
Component 5: The database engine.
SqueakDBX architecture
This is the hole architecture of the open source solution we propose for relational database access.
1) Common interface GLORP vs Drivers: We really don't know exactly (we are investigating this) how much coupled it's GLORP to the Postgresql or Mysql driver. Perhaps we will need to refactor, adapt (or whatever) GLORP to generate a common API between it and any driver. We put postgresql and mysql because we heard they are the only ones that exist.
2) SqueakDBX: This is our OpenDBX wrapper that will also be compatible with the API of 1).
3) SqueakDBX dialects: We really don't know if this component will really exist, but the idea is to have an specific dialect for each RDBMS so that the user of OpenDBX don't have to care about the specific SQL syntax.
External call implementation
We are very proud of our design. As an example, you can change the complete external call implementation very simple. Just add a subclass of OpenDBX class and us it. Actually, this is all we have to do in order to use SqueakDBX-plugin.
Using FFI
This is the default implementation we use. It is known that when you execute a external function trough FFI, it blocks the squeak virtual machine until the function returns. So, if the function takes a lot of time, the VM will be blocked for that time. Consider this situation for a RDBMS driver for a moment. It would be non usable at all. But, don't worry, this wont be the case of SqueakDBX. This is because openDBX work with asynchronous queries. This is the way it works:
- call to execute- an external call
- wait for answer (a request to ask if there is already an answer, otherwise, yields for N time)- another external call
- loop step 2 until there is an answer.
- retrieve result rows, one by one -an external call each one
Of course FFI calls happen, but there are many "micro-blocks", so the total time expended in each process is equal to the addition of all FFI blocks + squeak calculations. But is important to note that (2 parallel queries time) (query1 time + query2 time)..
Using SqueakDBX plugin
We have developed a SqueakDBX plugin to replace FFI blocking calls. This is still at beta state. You can see it in package OpenDBX-Plugin from Monticello. We should have better results with this strategy, but we did some benchmarks and there is no real difference between them. To use this external call implementation instead of the FFI one, you must evaluate: OpenDBX setOpenDBXPluginImplementation. If you change this and you want to put FFF strategy again, you can do this: OpenDBX setFFIExternalCallImplementation. However, remember this is only necessary if you change the strategy. If not, FFI is understood as the default one and you don't have to do anything.
Using Alien FFI
This will be done in future
