[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mico-devel
Subject:    Re: [mico-devel] CosTransactions
From:       Karel Gardas <kgardas () objectsecurity ! com>
Date:       2008-01-02 21:02:48
Message-ID: 477BFBF8.2020003 () objectsecurity ! com
[Download RAW message or body]

Laurent Marzullo wrote:
> Hello all,
> 
> I've done modification to MICO for CosTransactions.

First of all, thanks for the good start!

> Here the change I've done:
> 
> 1) configure.in
> Add '--enable-ots' configuration command line option to turn on cos
> transactions
> stuff.
> 
> 2) By changing 1), I had to run autoconf/autoheader stuf. This lead to a
> problem with
> util.h
> g++ -frepo -I../include -O2 -Wall -D_REENTRANT -D_GNU_SOURCE -DPIC -fPIC
> -c os-unix.cc -o os-unix.pic.o
> /usr/include/bits/mathcalls.h:205: error: declaration of ‘int
> finite(double) throw ()’ throws different exceptions
> ../include/mico/util.h:212: error: from previous declaration ‘int
> finite(double)’
> 
> 
> I'd then changed util.h (Perhaps this change is not really necessary
> with your build tools).

this is quite strange, but I also see you are using GNU C++'s repo
functionality, which I'm not sure is working well these days. Could you
be so kind and try to disable it?

> 
> 3) MakeVars.in
> Add ENABLE_OTS makefile variable.

Please change this to USE_OTS to be in line with all other services.

> 
> 3) sysexc.h
> Add TRANSACTION_UNAVAILABLE and TRANSACTION_MODE exception.
> 
> 4) The transaction service stuff is put into 'libmicocoss'. I'd created
> a directory
> coss/transactions with:
> - orb initilaizer
> - client request interceptor
> - server request interceptor
> - ior interceptor
> - CosTSinteroperation module
> - TSIdentification interface
> - TransactionComponent (based on 'CodesetComponent')
> 
> For server interceptor, I used a thread key to communicate between the
> incoming
> request and the associated answer. I'd assumed that 'receive_request' and
> 'send_reply' are executed in the same thread for a given request. I
> don't know if
> this is right or not. Could you tell ?

Yes, this assumption is right for both thread pool and thread per
connection concurrency models.

Thanks,
Karel
-- 
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com
_______________________________________________
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
[prev in list] [next in list] [prev in thread] [next in thread]