[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mapping data
At 8:24 AM -0500 12/12/03, Seth Gordon wrote:
>If memory serves, one of the architects of JBoss said that the big
>bottleneck in a J2EE application is the time spent marshalling and
>unmarshalling data that's going to and from a relational database.
>To avoid this problem, JBoss caches as much information as it can in
>Java objects, and minimizes the number of reads and writes to the
I do hope it's only caching metadata... I really worry when libraries
implement caching in multiuser, potentially distributed database
>It seems to me that a good data-mapping system would solve the same
>problem in the opposite direction, so to speak.
From what I've experienced, generally the biggest bottleneck is lack
of specificity. If you can generate special-purpose native machine
code to translate from the base structure to what you need you'll go
about as fast as you can, with code in the target language (java or
whatever) as the next fastest way to do it. People seem enamored of
general-purpose solutions--I've seen far too much code that at
runtime queries the structure of the data and builds up the objects
from that, rather than constructing special-purpose code targeted
just at one particular specific type of data. Generality, in these
circumstances, is for code generators.
Excessively expensive object creation is also a culprit. While I
suppose objects are always the answer, sometimes the question is
"What's a mechanism I *shouldn't* use to do this?"
(This is probably a place to take a shot at XML, given its popularity
as an intermediate form, but that'd just be cheap.... :)
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
email@example.com have teddy bears and even
teddy bears get drunk