Issue Details (XML | Word | Printable)

Key: JDBC-148
Type: New Feature New Feature
Status: Open Open
Priority: Minor Minor
Assignee: Mark Rotteveel
Reporter: Thomas Steinmaurer
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Jaybird JCA/JDBC Driver

Add support for new Firebird 2.5 Services API features

Created: 06/Oct/09 02:54 PM   Updated: 14/Jul/12 03:09 PM
Component/s: Services API
Affects Version/s: Jaybird 2.1.6
Fix Version/s: None

Environment: All


 Description  « Hide
The Firebird 2.5 Services API offers new enhancements like using NBackup, Trace, ... via the Services API.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Mark Rotteveel added a comment - 10/Mar/12 02:23 PM
Mail from Thomas in Firebird-Java:

Hello Mark,

I have added some Firebird 2.5 Services API enhancements to HEAD in
2009, which I guess are now included in the 2.2.0 Snapshot.

While things went smooth, there was one problem left (see below; my Java
knowledge is a bit limited compared to Delphi), which I hoped Roman can
have a look. Don't know if he had time at that time. I haven't the
environment for working on Jaybird anymore, so I would need to start
from scratch. Not sure if this can happen any time soon, although I
would like to have a recent Jaybird dev. environment.

Just letting you know, that there might be an outstanding/unfinished issue.

Regards,
Thomas


> I'm almost done. This includes:
>
> * Support for specifying the security database when working with
> UserManager/FBUserManager
> * Support for SET/DROP AUTO ADMIN MAPPING for the new role RDB$ADMIN in
> security database added to UserManager/FBUserManager
> * Support for (incremental) backup and restore via NBackup (new classes
> NBackupManager, FBNBackupManager)
> * Support for new shutdown/online modes in existing
> Maintenance/FBMaintenance
> * Support for Trace/Audit API (new classes TraceManager, FBTraceManager)
>
>
> There is one problem left, where I'm stuck.
>
> When starting a trace via the Services API, the trace session gets
> registered successfully (I can see the trace session when listing all
> registered trace sessions). The caller (my test application)
> automatically waits for incoming data from the service query (pretty
> much the same when e.g. listing on the verbose output of a backup).
>
> Although I've registered System.out in my test class as logger, there is
> nothing streamed to System.out, even if events took place, which can be
> inspected in the written log file by the Firebird engine.
>
> When stopping this particular trace session from an external
> application, my test application gets terminated correctly, so beside
> starting a new trace session, this gets recognized as well.
>
> I've tried executing executeServicesOperation(...) in the main and in a
> separate thread. No luck with both.
>
> I'm stuck here.
>
>
> Regards,
> Thomas

Mark Rotteveel added a comment - 10/Mar/12 02:24 PM
Need to investigate this before Jaybird 2.2 release

Mark Rotteveel added a comment - 18/Mar/12 03:22 PM
Trace does work, but I think its implementation may need an overhaul to make it more usable. I think the current implementation requires a lot of effort from its users and I don't feel comfortable with the way data is being read and sent to the user and how sessions can be tracked and stopped (this also applies to some of the other service manager implementations). The fact that it creates a separate thread for every trace session might swamp a computer *if* a lot of sessions are traced.

I don't think I will make drastic changes for Jaybird 2.2, but I will consider a reimplementation for Jaybird 2.3 or 3.0.
Some rough ideas I have:
* Builder object for creating a trace request
* Use executor framework with a bounded thread pool and schedule individual reads instead of using threads per session (might be a bad idea if a trace read blocks if no info is available)
* Encapsulate trace information (might be hard to do, need to investigate trace further)
* Use queues and/or events for communicating with user of trace session instead of streams (might not be easier though)

Mark Rotteveel added a comment - 14/Jul/12 03:09 PM
Using a NIO implementation might be an option as well.