I'm not sure what this Oracle raw thing is, but I am pretty sure you don't
want to be doing it. Use the indexes on primary key it'll be plenty fast.
Just make sure tuned updates can be turned off since with Oracle it'll
probably run faster with tuned updates off because the database won't have
to be parsing all those odd statements. Of course for those people whoses
rows are 32K long YMMV. By the way, does it use prepared statements either
way?
Where in the code does this select version thing go? Is this just done to
see if you've got the right version in cache?
Cheers
-----Original Message-----
From: danch
To: [EMAIL PROTECTED]
Sent: 5/7/01 1:01 AM
Subject: Re: [JBoss-dev] TODO: JBossCMP 1.1 FAST!
I was about to tackle the most significant performance related problem
in JAWS (see the discussion and feature request on "CMP and finders:
optimized" and "optimize collection finders", respectively)
I've been building database applications for quite a while now (damn
near the only thing i've ever done, software-wise) and am willing to
take this task on.
More comments follow in-line.
marc fleury wrote:
> OK,
>
> I now believe that I am staring at a simple fact. The PERFORMANCE IN
> CONTAINERS IS BOLONEY!
>
> Our container can run in 0.05ms (yes **m**s) and still excercise 80 of
its
> features. what costs a lot is **serialization** and we find that in
JDBC
> calls and network calls.
>
> It appears that our JDBC calls are not optimized at all. We know it
is just
> JawsCMP but it is what people really look at when they work on JBoss.
There
> are tons of optimizations such as using "raw" ids in the database
(Oracle).
> The way we would work this is that we could then map the primary keys
to the
> raw ID (simple map) and the lookups would be kick ass fast.
As a first step here, I'll make the 'command factory' used by JAWS for a
container configurable. This will make it easier to make DBMS specific
implementations of certain commands.
>
> I believe we also implement correctly the "isModified", but we could
really
> do a "getModified" that would return the names of the modified fields.
We
> could then bypass the "tuned" updates.
Personally, I'd rather keep the 'tuned' updates code, since it requires
no-more container specific code. What's done now mirrors the behavior of
Borland's CMP implementation, which is a very developer-friendly system.
What do you see that's bad in the tuned updates?
>
> Finally the load today is very blind and very stupid. We just load
> everyone. A simple implementation of the "versioning" pattern in the
> database (where we add a field that is the version of the record)
enables us
> to get the right version in little time and saves us time in loading
since
> we can just "select version where rawID" for example :)
This is a fine optional feature. I've implemented this in BMP beans and
it shouldn't be too hard to add.
>
> If you are interested in leading this effort and have serious db
background
> please let the board know
>
> marc
>
>
> _________________
> Marc Fleury, Ph.D
> [EMAIL PROTECTED]
> _________________
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
