db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: [PFE] locking via database for multi-VM environment
Date Tue, 23 Dec 2003 14:37:46 GMT
On Dec 23, 2003, at 4:00 AM, Thomas Mahler wrote:
>> 3) don't use database at all, have simple lock manager with RMI 
>> interface, it should keep all locks in memory and automatically 
>> remove timed out locks. This will work much faster than database 
>> operations. If you take seriously the Prevayler's idea to keep all 
>> database records in memory, :o) it would be reasonable to assume that 
>> there is enough memory for locks.
>> +: faster, no explicit limits
>> -: implicitely limited by available memory
> I like no 3. ! In fact my whole idea of a LockManager was inspired by 
> the LockServer of the OO database Objectivity. In Objecttivity the 
> Lockserver is a separate server process that works exactly as you 
> describe it in 3)
> I would like to see it implemented as a servlet. If we ship it as a 
> servlet we don't have to implement a complete server infrastructure, 
> but could rely on the servlet engine.
> For me this is the best solution, as I really don' like to use a 
> database application that limits scalability by the numer of supported 
> columns.

The LockServer idea is not bad at all, I think. However...

I definitely wouldn't ship it as a servlet. HTTP is a crap protocol for 
RPC/RMI. Sam Ruby can tell you all about why it is inefficient far more 
eloquently than I can, however. If we wanted to write a general 
transaction/lock manager that supported non-OJB, or non-Java clients 
than there is an argument to be made. Until then, even straight RMI is 
far more efficient. A simple socket-level protocol is probably easier 
and definately more efficient.

If I get shot down on avoiding an HTTP mechanism, consider at least 
using a standardized RMI over HTTP mechanism, SOAP, and ship it built 
around Axis. I still think this is a Bad Idea from a performance 
perspective though.

A better solution yet is to make the implementation pluggable -- you 
can run against a lock server, against a 500 (or 50) node cap database 
stored system, etc.


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message