> So, i guess a conclution would be to use sql wrapped in session beans when
> the transaction load is greater than 1000 (which is quite a huge load :-)
I doubt it will help. If the container starts sinking, it is most likely
because it's running out of container space (lack of memory) or running out
of CPU cycles. If you displace the load to the database system, you assume
that it will better manage its hidden container/buffers and require less CPU
cycles. Now, this could be the case, but it's definitely unproven.
> Generally i don't like the thought of building on a technology that i
would
> need to hack around and directly access the database again, by-passing the
> ejblevel. Hopefully that is NOT the case in 99% of the cases.
I would stick to the ejblevel and give this technology the benefit of the
doubt for optimizing its caching strategy.
I think, however, that the process of grabbing primarykeys as to know which
entity beans are part of the requested result, should be relegated to the
rdbms, by sending the appropriate Sql statements to it.
Usually the rdbms will use well-cached indexes and will very often not even
have to hit the disk to tell you which primarykeys are part of the
resultset. Then you can iterate (hasNext(), next() ) over these primarykeys
collections to grab their payload one by one in the entitybean container,
where a decent number of them should still be kept in cache by the container
manager.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
