It's true the C library linking issue must be covered in next C language spec. I filed a related issue https://forge.gridforum.org/tracker/?aid=1141 ... before I found existing #1127. Andreas On Wed, 17 Nov 2004, Peter Troeger wrote:
Daniel Templeton wrote:
I don't see how the ODBC model can work for multiple concurrent connections. I actually don't see how it can work for concurrent access to a single connection. Maybe I'm missing something, but the JDBC model seems much better suited to DRMAA's needs. I would love to hear arguments to the contrary, however.
You may try to see it from a C perspective. In the ODBC world, all C application's link to the same shared ODBC library. The availability of drivers is therefore a question of local system configuration. A database application starts with the ODBC connection method, which leads to the loading of a particular database driver library. The function returns some kind of connection handle, which is then used in all further method calls.
For DRMAA this would mean that we have one driver manager implementation, e.g. in C. Beside this there is a set of DRMAA driver libraries for the different DRM systems (libdrmaa2sge.so, libdrmaa2condor.so, ...).
What I like about the ODBC idea is that you could move some implementation effort exclusively to the driver manager, which makes life easier for DRM vendors. The manager could be responsible of parsing partial timestamps, while the driver interface only takes complete timestamp information in the job template. Consistency checks for job templates could be done in the manager only, so that the drivers can rely on valid job template structures as input. run_bulk_jobs() may be an optional method for a driver implementation - in case it is not supported the manager implementation could use a simple loop and the job_run() method.
The manager may also offer a DRMAA 1.0 as well as a 2.0 / 3.0 / ... DRMAA interface in the future, so that we have backward compatibility for the applications even if the specification evolves.
Another advantage is more or less C-specific : In the moment I need to re-link my application if I have more than one DRMAA library on the system and want to change the targeted DRMS. With a driver manager architecture I can have multiple DRMAA driver libraries on my harddisk and all of them are usable by the application without re-linking.
I know that we talk about a lot of stuff here. We should clearly figure out what are the most emerging things to be solved. For me these are the once-only partial timestamp implementation and the C-library linkage issue.
Peter.
Daniel
Peter Troeger wrote:
Clearly, Peter, you have something in mind, and I think that maybe I am missing your point. Why don't you walk us through how you would implement the driver model...
Ok, let's take one step back. Maybe I am wrong, but I think the concepts of ODBC and JDBC differ for the role of the driver manager.
In ODBC, all end-user applications talk only to the driver manager library. It offers some functions for submitting a query, fetching results, using cursors and so on. There is even a special ODBC SQL subset, which can be used by the application regardless of the driver type. Because of this concept, the driver manager is able to perform additional tasks for functionality offered to the application. It must also convert ODBC SQL to database-specific SQL and must map data types and error codes to the ODBC-specific definition.
In JDBC, all drivers share a common interface. The driver manager is only responsible to load / maintain the driver instances, but the application performs functiona calls directly to the driver instance. Since the driver manager is left out during the work with the database, there is no possibility to implement parts of driver functionality (like cursor handling) in the driver manager.
If this picture is correct, than we should first discuss which model is more appropriate for a scenario with multiple DRMAA libraries on one machine.
Peter.