Jeremy Boynes wrote:
David Van Couvering wrote:
Hi, Jeremy, I like your idea of a "revolutionary" branch but (a) have
no idea how to set one up and (b) I don't think I have the "karma" yet
to do it.
a) is easy, just svn copy what you need to a suitable location under
'branches' and merge in your local changes. When the revolution is over
the branch either gets merged to trunk or deleted
To do that you need b) which is blocked waiting for root to create your
account.
OK, thanks
I also was planning to do what you call "small but crucial
refactoring." First glance was not that promising though. I have
been able to keep out all the storage-related services, for the most
part.
This really isn't about the embedded JDBC driver being tied to the
engine. It's more that the services themselves have lived a long life
under the assumption that they're running within the engine.
Which services are involved and can we isolate them? I would have
thought that the JDBC code could use a form of "in-VM" transport to
separate itself from the engine at a much higher level than the storage
level.
I'll try to summarize all this once I have worked through things a
little more myself.
I would also wonder if there is a need for an "in-VM, cross-classloader"
configuration that would allow multiple applications to use different
JDBC versions but a common engine. I can see use for that when Derby is
embedded in an IDE like Eclipse or in an appserver where the engine is
running separate from the applications (e.g. different protection domain).
An interesting idea, kind of like local EJBs. My understanding is right
now each application has its own database environment, and you can't
share data across applications in an app server -- going across
classloaders is pretty much identical to trying to go across VMs -- not
allowed if you're running embedded mode.
I may be mistaken, but I don't think you can solve this through futzing
with Java VM semantics. I think you need an "in-memory" version of DRDA
-- perhaps using a memory-mapped NIO buffer as a DRDA message queue...
Way beyond the scope of what I'm working on :)
David
--
Jeremy
