Re: Sniffing redo logs to maintain cache consistency?

Yes, I'm also discussing this with our DBA. However, we're not designing anything, only discussing what options are available.

The reason I favor moving business logic from the database is because, for one, most of our developers are Java developers. Also, this makes it easier to provide an elegant business object layer, where business objects can be accessed even remotely. So, instead of having just java objects that map to a record in a table and have business logic implement in some other stateless objects calling PL/SQL, this would allow to have one object store state as well as have methods implementing business logic. That seems very elegant.

It's also nice to use an O/R tool, such that objects can be persisted automatically, reducing work on developers. So, the reasons are developer productivity and a clean object model, and all that should also perform well. From what I read, it is critical to have efficient caching when doing this, otherwise performance will suck. If we still have some business logic in the database, then caching is difficult.

Sorry I started out with the most complex solution... I do want to keep it simple. And maybe it is a bad idea to move business logic to Java afterall.

Thx
Andrej

Donovan R. <mdonovan_at_hotmail.com> wrote in message news:<a2oi5v8fsajjb0iitosgga1pk8f0llgbln_at_4ax.com>...
> Andrej, have you a DBA working in this project?
>
> Moving business logic from the database to the app server is done for
> the portability, not for the performance. Until now, nothing is more
> fast than the PL/SQL. You can avoid "the network problem" by plugging
> a cross cable between the aps server and the database server(with
> dedicated network cards). How could you know that there are JDBC
> overhead? You base that by measuring CPU on the application server for
> the java threads? You already said that the CPU usage of Oracle is
> high; I presume that you measure that on the database server. My
> conclusion is that your java threads in the application server are
> waiting for the database to return the results. In this case, scale up
> you database server. At least fix one side of the problem. You hope
> that having a "virtual database" loaded on the app server will fix the
> problem? Have someone made a diagnostic on the database? Have seen why
> the CPU is high? Is there hard disc contention? How much controllers
> the server has? Have you using indexes? Believe me, I have seen people
> working for Oracle that ignore the existence of the indexes, at least
> on the system I saw, there was indexes only with names like
> "SYS_C001...." so, created by the system for the primary keys.
>
>
Received on Mon Feb 24 2003 - 05:49:55 CST