[drmaa-wg] Java Binding Questions

[Andreas Haas]

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