Shall we drop c/s mode?

[Thomas Mahler <th...@apache.org>]

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

Re: Shall we drop c/s mode?

[Josh Morris <jo...@unitt.org>]

I have fixed the c/s mode for a product at our site and I am happy to
give that fix to OJB. However, I agree that the performance is lousy, I
am actually trying to remove the usage of it. The time required to
handle this effectively is non-trivial. I personally feel, for whatever
it is worth, that there are other areas that really benefit from the
time.

Josh Morris


On Sat, 2003-01-25 at 13:38, 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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Shall we drop c/s mode?

[Brian McCallister <mc...@forthillcompany.com>]

Follow up to my previous:

Re-read Thomas's original email - somehow I missed the 10x slower than
running in singlejvm mode. Ouch. Ignore my thoughts on using it a
"cheap" integration layer or anything else equally ridiculous.

Goes back into hole to figure out OJB stuff.

-Brian

Re: Shall we drop c/s mode?

[Brian McCallister <mc...@forthillcompany.com>]

I'm not a voter (in fact I am pretty much just learning OJB right now),
but I would very much prefer it not be dropped.

1) It is one of the points that sold my company on looking hard at OJB
(pretty much sold on it, actually, but this is part of the reason).

2) Integration into clustering in various application servers doesn't
always work for clustering a given application. For instance (this is
very much for real, though the project started as a learnign exercise) I
have used OJB as the persistence/integration layer for a simple
timetracker application for our part-timers. This application runs on
Tomcat right now. Happy fine. The next step is to write a simple command
line client to it instead of the web (a good third of our part-timers
prefer command line to web based ui's, is sorta nice). So... I A) go to
remote objects for the application (ick), B) turn off all caching and
use the database as the integration layer (ick ick), C) write an http
wrapper for calls that emulates a web browser (via HTTPClient or
somesuch) (ick^4), D) subclass the Struts ActionServlet to add startup
code to launch a thread to listen for simple TCP/IP traffic from the
command line client and have it use the same API to the business logic
in the same servlet container (messy messy), or.. a bunch of other
possibilities, but the one I LIKED was being able to use OJB in C/S mode
as an integration layer where OJB would keep the business objects
synchronized for me across JVM's without adding the overhead of remote
objects - I could bundle up the business logic in a jar, write a new
control layer (regular socket listener and parser) and a new front end
(the remote command line client), or whatever. The nice part of this is
it just takes telling the two applications running OJB about each other
and (presuming they are running on the same network) we get fairly
inexpensive, no-new-firewall-rules-on-the-client-side, added interfaces
and synchronization on completely seperate server apps. Pretty cool.
This application doesn't require C/S levels of scalability, but it is a
nice project for playing with the technology.

Not everyone runs in a fancy clustered Web or EJB container, or wants
to. The ability to deploy to a simple JVM (or four) is a big plus.

3) If no one wants to maintain it or sees value in it I will devote
higher priority to getting my butt up to speed and offer to do it.

I don't know how efficient C/S mode is right now (as I said, my next
step in learning OJB was to learn how to do it in the aforementioned
project) and pushing a remote-object integration layer may be more
efficient, but I really doubt it, and it requires a lot more from the
environment (RMI server and open ports on the client at a minimum unless
you really like polling for changed states).

-Brian

Re: Shall we drop c/s mode?

[Eelco Hillenius <ee...@topicus.nl>]

We're not using it for our projects. There are better area's to work on.

Eelco

----- Original Message -----
From: "Jakob Braeuchi" <jb...@gmx.ch>
To: "OJB Developers List" <oj...@jakarta.apache.org>
Sent: Sunday, January 26, 2003 4:49 PM
Subject: Re: Shall we drop c/s mode?


> +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:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>

Re: Shall we drop c/s mode?

[Jakob Braeuchi <jb...@gmx.ch>]

+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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>