[drmaa-wg] Java Binding Questions

[Daniel Templeton]

I think I get it.  The ODBC client then passes the connection handle to 
the driver manager with every operation, right?  If so, let's translate 
this idea into the OO world.  Hmmm... We have a connection handle that 
we have to pass into every method.  Perhaps we should make a Connection 
object that implements the interesting methods.  It can then forward 
requests to the driver for which it was built without the developer 
having to keep track of an extra parameter.  Viola!  We just arrived at 
the JDBC model. :D  (Or am I still missing something?)

Aside from your first paragraph below, the JDBC model and the current 
DRMAA factory model do everything you describe.  The API/SPI model that 
both use achieves the same ease of implementation as the ODBC driver 
manager.  Of course, I have the freedom to work in a purely Java world 
without having to worry how this is going to work in FORTRAN.Net. :)

Perhaps we need to define more clearly what we're trying to solve.  I'm 
solving the driver problem in a purely OO world.  It sounds like you're 
trying to solve it for everyone, and that's fine.  There are other 
places where the .Net spec purposefully includes things from the non-OO 
spec, even though we agree that they aren't needed in an OO spec. 
You're not defining a purely OO spec.  So, what problem are we trying to 
solve here?

Daniel

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