db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Shall we drop c/s mode?
Date Sun, 26 Jan 2003 15:49:02 GMT
+1 for dropping it when no one uses it anyway

Thomas Mahler wrote:

> Hi all,
> I'd like to have a decision how to proceed with the client server mode.
> It has not been properly maintained since the 0.9.7 release and a lot 
> of junit tests fail.
> It won't be impossible to fix it, but still a lot of work.
> But before we start to repair it I'd like to discuss if there is a 
> really a "business need" for c/s mode.
> The original idea was to show that OJB is scalable in itself. But I 
> doubt if this is really a requirement.
> If there is a scalibity issue in an application it will be in most 
> cases in the web- or EJB-tier. If an Application is clustered accross 
> multiple J2EE containers it's quite easy to use OJB in singlevm mode 
> and let it share the clustering.
> If the DB is the bottleneck you can use DB clustering. So I don't see 
> a real demand for OJB clustering in this context.
> The only possible usecase I see for C/S is:
> If a client app should not use a JDBC driver but still be able to 
> access a DB. In this case OJB c/s mode could be a solution.
> But is this a scenario we have to cover?
> The C/S mode also has some disadvantages:
> - It is really slow (at least 10 times slower than singlevm mode!)
> - it produces extra maintenance costs
> - it is a burden to integrate it into the junit testruns (takes 20 
> Minutes or so...)
> - Users are often confused about C/S mode. Some users think that it 
> could be a replacement for an app server...
> Am I missing something fundamental? Do we still need c/s for some reason?
> Of course we should also ask the users before we drop this feature.
> What do you say?
> cheers,
> Thomas
> -- 
> To unsubscribe, e-mail:   <mailto:ojb-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ojb-dev-help@jakarta.apache.org>

View raw message