[drmaa-wg] Java Binding Questions

[Peter Troeger]

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.
>>
>>
>