[OmniBase] Support for distributed computation

Ominibase is good but so far, I'm only using it inside an homogeneous
intranet environment ( in the same Domain segment,  queried using
virtual disk name , not ip address) via its supported default.
    I need it be run as a server independently and the database could
be accessed via internet tcp/ip protocol, or support distributed
ORB-like object capacity.
   I tried using some free goodies  for the distributed computation
request but feel quite inconvenient ( there are some problems in
resolving client address, I'm workig on it).
   I felt it would be a great achievement if OA could provide such a
working standard or Omnibase has its own solution.




Best regards.

Tk Kuo

Hi,

You can use OmniBase + Swazoo Server.

If it possible you can distribute your respository with ODBContainers, but
you must have a configurated LAN.

Regards Bruno

"kuo" <[hidden email]> escribió en el mensaje
news:[hidden email]...

On Thu, 29 Jul 2004 11:52:45 -0300, in comp.lang.smalltalk.dolphin you
wrote:

>Hi,
>
>You can use OmniBase + Swazoo Server.
>
>If it possible you can distribute your respository with ODBContainers, but
>you must have a configurated LAN.

Thanks for your  hint.
   I study the related codes through ODBContainers and find that they
all rely on ODBFileStream for file-stream manipulations, which are
tightly bound with Windows OS kernel's file system working, i.e. they
all need conventional dirname/repository pathname stored as instance
variables as default, not "ip address" that I wanted.

   I supposed initially that I can redirect the ODBFileStream to
SZReadWriteSocketStream but it is not such an easy case that I could
handle ( **try looking inside ODBFileStream class, there are OS call
related stuffs everywhere that could not be replaced by
SZReadWriteSocketStream ).
 
   I don't have clear concepts about ODBContainers's function in
OmniBase and its utility, I just use plain OminBase openOn:, maybe you
can give me more help.

  **My point is that could OmniBase be tuned to function at such a
large scale under mature multi-way server-client ( GemBuilder, Object
space, cached pages, choices of DLL, RMI calls, etc)  artitectures as
GemStone/S does** .

Best regards

kuo

kuo wrote:

>    I supposed initially that I can redirect the ODBFileStream to
> SZReadWriteSocketStream but it is not such an easy case that I could
> handle ( **try looking inside ODBFileStream class, there are OS call
> related stuffs everywhere that could not be replaced by
> SZReadWriteSocketStream ).

If I'm understanding you (and OmniBase) correctly, then I doubt whether this
approach would work.

The abstraction that OmniBase needs to be given is that a "file" is an abstract
"array" of bytes, where the program can read arbitrary sub-sequences, and lock
and unlock arbitrary subsequences, and where the OS will ensure that the
"array" is written to disk at controllable times.

SZReadWriteSocketStream (or any other Stream that is ultimately a wrapper
around a TCP/IP stream) is nothing like that.  It is not seekable (there isn't
and can't be a working #position: method).  There is no sense that you can go
back to read what you have previously written. And you can't lock subsequences.

If I were trying to do this, then I think I'd try to create an object that
looked like an ODBFileStream but implemented all the operations by sending
requests over the network.  E.g. a request to lock a region would be sent over
the network as a single request.  A request to read 33 bytes would be sent as
single request (and the answer would include the 33 bytes).  You mentioned that
you've tried something that lets you do remote access to existing objects, and
I suspect that it might be worth trying that again, using it to allow remote
access to the ODBFileStreams.  Presumably, the best way would be to find the
20-odd places that refer directly to ODBFileStream, and refactor them to use a
factory pattern.

A lot of work :-(

BTW, don't forget that you'll have to deal with the case where clients crash
without releasing locks.

    -- chris

"Chris Uppal" <[hidden email]> wrote:

A lot of work indeed.
An easier solution might be to use GOODS; I know someone was working
on porting my client library for this to Dolphin, so hopefully that's
available by now.  It's a slightly different feel from using ODB, and
so you'd have to do a little bit of work to port your code to use it,
but if you really need an OODB for Smalltalk that you can easily
distribute over the network, it's the best thing I know of short of
Gemstone.

OTOH, it certainly would be nice to have a network layer for OmniBase,
so maybe I should be quiet and let you implement that... ;)

Avi

"kuo" <[hidden email]> wrote in message
news:[hidden email]...
My experience is that it is usually very difficult to add distributed
processing or client/server capabilities to the application that has not
been designed for it from the start. I have not looked into OmniBase, so I
may be wrong, but databases built around flat file access can rarely be
scaled to work good in C/S setup, especially over links slower than LAN.

rush
--
http://www.templatetamer.com/

OmniBase code which is currently released is not suitable to work in WAN
environments. It is optimized for file system access.

I wouldn't recommend doing an ODBFileStream wrapper over TCP/IP because this
wouldn't be very efficient (most probably it would be too slow for practical
use). For instance a transaction commit would require a lot of unecessary
network roundtrips, whereas a clean TCP/IP solution would first form a
proper commit request and send it to the server in a single network
roundtrip.

In the past I have done quite some work developing a C/S solution with a
TCP/IP server and a client which uses only sockets to connect to a server. I
already had a version where you could do database reads and was about to
implement transaction commit. But then other more important thing arrived...

If you have a real project with a budget which could partialy cover
development costs of a real C/S solution please contact me via e-mail. A
real C/S object database would also be portable across all Smalltalk
dialects.

Best regards,

David Gorisek




"Avi Bryant" <[hidden email]> wrote in message
news:[hidden email]...
> "Chris Uppal" <[hidden email]> wrote:
>
> > If I were trying to do this, then I think I'd try to create an object
that
> > looked like an ODBFileStream but implemented all the operations by
sending
> > requests over the network.  E.g. a request to lock a region would be
sent over
> > the network as a single request.  A request to read 33 bytes would be
sent as
> > single request (and the answer would include the 33 bytes).  You
mentioned that
> > you've tried something that lets you do remote access to existing
objects, and
> > I suspect that it might be worth trying that again, using it to allow
remote
> > access to the ODBFileStreams.  Presumably, the best way would be to find
the
> > 20-odd places that refer directly to ODBFileStream, and refactor them to
use a

On Mon, 2 Aug 2004 10:51:55 +0200, "David Gorisek"
<[hidden email]> wrote:

>If you have a real project with a budget which could partialy cover
>development costs of a real C/S solution please contact me via e-mail. A
>real C/S object database would also be portable across all Smalltalk
>dialects.
 
    How I would expect  this enterprise-strength real C/S object
database be enrolled at one of your company's flagship product as
OmniBase and STS are so that everyone wanting a future for seamless
computing has the one under affordable budge.  
:-)Just  my 2 cents (-:


Best regards

Tsun