Distributed Object Container

i hope you plan to make it more then just a WEB App Server! rather make
it a more general App Server eith the Web part as an option.

~transami

···

On Wed, 2002-08-28 at 03:47, Nat Pryce wrote:

On Wed, 2002-08-28 at 04:23, Jason Underdown wrote:

Instead of bickering over J2EE, let’s exchange ideas on how we might
build such a thing. My first course of attack is to read through
Matsuo Hisanori’s Petit+Server and check out his ideas.

For the web GUI side of things, you might want to look at WEBrick and
Amrita (both in the RAA). WEBrick is a Ruby framework for building
servers, and provides Ruby servlets for HTTP. Amrita is an XML and
HTML template system that provides a clean separation between code/data
and presentation.

I remember your post but already made a db persistence mixin myself.
What I actually want goes a little further: transactions not tied to a
db. That’s why i used the example above, a cart usually is held in
memory and not in a db. Or think of atomic transactions spanning a db
and files or a printer (mark bill as printed in db if and only if it’s
succesfully printed).

-billy.

···

On Wed, Aug 28, 2002 at 05:41:58PM +0900, Tom Sawyer wrote:

On Wed, 2002-08-28 at 02:04, Philipp Meier wrote:

I recently stumbled over OJB (http://jakarta.apache.org/ojb/) which is a
object relational bridge including a ODMG 3.0 complient API. Although I
didn’t tried it yet I think something like that is missing for ruby. Of
course, the API must be ruby like. The concept of blocks in ruby would
be great for transaction demarkation (sic?), e.g. I imagine writing db
access or generally access to persistent object like this:

def add_item_to_cart(item_ids)
transaction.serializable do
@warehouse.queryByValue(:id, item_ids) do |item|
item.instock -= 1
@cart[@item] += 1
end
end
end

while your example is bit more then i have yet provided, if your are
interested in being able to move you objects in and out of a database
with minimal fuss, i have created DBize (soon to be released as well) it
is primarily a mixin module that makes an object instantly
“relationable”. it also provides for subrecords (i.e. many-to-one table
relationships).


Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0
eLösungen 89077 Ulm Fax: +49-731-399 499-9

ah, i see. hmm…that’s an intersting notion. and i think i know how to
do it! maybe you have already done it, but, simply store the binding
(see kernel#binding) at the start of the transaction, upon an error you
can reinstigate(?) the stored binding. simple, yes?. of course db
transactions would take care of the db side of it.

thanks for this. it’s exactly what i need to add to GUtopIa! (not to
mention a few other potential projects) killer!

~transami

···

On Wed, 2002-08-28 at 04:15, Philipp Meier wrote:

I remember your post but already made a db persistence mixin myself.
What I actually want goes a little further: transactions not tied to a
db. That’s why i used the example above, a cart usually is held in
memory and not in a db. Or think of atomic transactions spanning a db
and files or a printer (mark bill as printed in db if and only if it’s
succesfully printed).