[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accessing Ozone from a servlet

On Tue, 18 Jan 2000, Eric van der Vlist wrote:
> Hi Falko,
> If I get it correctly, then you'd probably loose more by the lack of
> concurrency than, you'd gain by avoiding the socket communication and
> it's better to access ozone using a remote database in a servlet...
Hmmm... I'm not sure. This highly depends on your requirements. If you have to
serve 100 concurrent users, then I would use a separate machine for
scalability, anyhow. In other cases one local database connection could be okay.

Another option is to enhance ozone to make a connection accessible from
different threads ;) (and use LocalDatabase even for 100 concurrent users;)

> To come back on the serialization issue, does it means that there is a
> trade-off to find between "small objects" which will mean a huge
> serialization traffic but a good concurrency (as the locks are handle at
> the object level and transactions per method call) and "fat objects"
> with big methods which will mean less serialization (they can handle
> more by themselves) but less concurrency ?
... in general, yes. The current transaction model of ozone (implicite
transaction demarcation) naturally leads to "big methods". This is the idea
behind the implicite tx demarcation: force programmers to put all the code of
one transaction inside one method to reduce the communications overhead of the
RMI architecture.

I'm not sure about concurrency. In a specific application domain a transaction
is a transaction. This does not depend on the tools you get from the database.
In other words, you will probably get an incorrect algorithm, if you separate
code of one transaction just to get better concurrency. But if it *is* possible
to separate the code, then you can do this also with the implicite transactions
of ozone.

Falko Braeutigam                         mailto:falko@softwarebuero.de
softwarebuero m&b (SMB)                    http://www.softwarebuero.de