At 12:23 PM 11/22/00 +1100, Mark O'Donohue wrote:

>
>Maybe this shows my ignorance but what is netfrastructure, and have you
>implemented this yet or is it still in the design phases?
>

Netfrastructure is a deployment platform for packaged Internet solutions.
A Netfrastructure application can be downloaded, installed, customized,
and maintained by browser. It also supports an arbitrary number of
independently customized applications on a single server. Netfrastructure
has an embedded content store (a JDBC compliant, transaction based
content store, if you get my driver), an integrated search facility,
and an html generation engine so sexy it boggles the mind.

Of course I implemented it.

>
>But the trickiest part that I see is having all the backing up details
>that support the Connection parameter that is passed into the java code.
>This implies you also have implementations of Connection, Statement,
>CallableStatement, ResultSet etc that link back into the current
>connection being used by the transactions, probably back through native
>C calls. I assume you have something (NfsConnection, or know of
>something) that does this. It is not possible, as I see it, to use
>interclient in this way.
>

Interclient sucks. Dump it and get on with life. I'm Netfrastructure
and not Interbase (a registered trademark of dishonest crooks). But
I would take your observation and let it drive to effort to push
JDBC semantics deep, deep into the engine as alternative language
subsystem. The thread semantics might tie you knots, however.
Clean up the threading in the engine is probably more difficult
than achieving peace in the middle east.

>Also I believe that the implementation will probably work differently
>for super server and classic. For example in super generally I would
>expect we have one instance of the virtual machine and variables will be
>shared amongst all open databases. Whereas with classic, running as a
>service, there will be probably one per client, as their would be for a
>direct local connections. Java static or "global" variables will act
>differently in these cases.
>

Which is a good thing. Screwing up global variables is good for you
in the long run. Restrict yourself to either local or intergalatic
variables. Unchaperoned relations between connections is a capital
offense in eight states.

There is an important issue here. A close examination of the sample
shows Conection.getAttribute and Connection.setAttribute to pass
the effective user agent from application code to the trigger. The
standard USERNAME for the login account was useless since it was
always the account used by the Web server module to connect to the
database, er, content store.

>
>A super server running one java virtual machine (or a few) could be a
>good thing, but also may be a pain, for instance if you use the same
>trigger in several related databases or even several tables in the same
>database you would have to resort to some tricks to keep local
>statistics in java for each seperate call.
>

What's wrong with using the same trigger? There would be only one
JVM, of course. But depending on implementation each server,
database, or connection could (implementor's choice) has independent
Java spaces. Anything that makes illicit relations unreliable is
good. But with memory a buck a meg, don't sweat the small stuff.

>It might be worth considering not calling a static method, but a real
>object with some ability to control scope of the object, say being able
>to declare that it exists at a global, database, table or per call
>level.
>

Let the static call do it. Keep the interface small and clean.
Make easy stuff easy, hard stuff possible, and unsanitary operations
a real pain the butt.

Jim Starkey