As David pointed out these interfaces are non-public and not meant to be
used by applications, Derby provides no guarantee that any external 
access to these files will work in any subsequent release.  The current
implementation is very physical in that it basically logs the byte 
changes per row at the per page level.  Attempts to read the log while
the system is running may cause failures in the Derby system (for 
instance on window we may fail when trying to delete a log file if it
is open and being read by another application).

No work has been done to provide a public API to the log.  They are 
quite user "un-friendly".  It might help
if you said what your goal was in this application.  An example of Some 
things that make it unfriendly is that a single insert to a user table 
(even without
indexes), may generate many insert log records at the physical level.

An example of what might be done to provide a user level view of 
changes, might be to log logical log records associated with each
operation.  Then some interface could be provided to read just these
logical view of changes.  Such an implementation might be done by
creating a new module in derby which extended the current language
statement nodes which make changes to the db and do the extra work
necessary to logically log the information.

Bonnie Wang wrote:
> Hi,
> 
> I'm trying to develop an application that make uses of Derby's transaction log.
> It seems there's no public API for external access of the log.
> 
> I have been looking through the source code for days trying to figure out how to
> make sense of the log files, but, as it turned out, I always get stuck when it
> comes to a class called LogToFile. This class seems to be the core part of
> Derby's logging system, but I couldn't find ways to instantiate it from a given
> file system path just like other files, which should make sense.
> 
> Could someone give me some help? Thanks a lot!!
> 
> 
> 
>