[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
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk