Enrique Medina wrote:
Umm, I see.
But shouldn't it be interesting for this specific problem to just have
some kind of callback mechanism in the DataModel, so you could 'do
something' everytime a row is rendered?
Actually the current datamodel interface has such a method, getRowData
is called every time a row is rendered and then the row counter is
increased.
Sure you theoretically could open a session every time a row is
rendered and then drop it, that might work for small prototypes, but
you basically push the performance down the garbage (sorry for the pun)
if you do that, because in the best case sessions get recycled
and transactions are opened and closed constantly, in the worst case
the sessions also are opened and dropped every time you
have a row fetched.
I think you get the picture on where the basic flaw in the current
datamodel mechanism is. The current datamodel mechanism is basically
only suited to situations where you can keep the connections open (and
also the transactions if possible), because of the missing callback
points which notify the model on when it can aquire resources and drop
them again.
You might get around that problem to a certain extent by using JTA, but
I am not too familiar with it.
(The studio creator uses it to bypass the problem)
I mean, you could get a reference to the current object in order to
reattach it to the new session...
Well you cannot keep the sessions open forever, I am not sure on what
you want to do, but if you have more than a handful of users, you should
drop the session after the entire page is rendered, after all you dont
know what the user is going to do.
Once you write the object back you have to reattach the object anyway to
the next opened session, which is responsible for the write back.
What do you think? Maybe it's as simpler as reimplementing the actual
DataModel with callback mechanisms...
Well to my knowledge you cannot avoid having to implement the entire
datamodel mechanism and then you run into the scope problems, which are
also connected to your lazy loading problems.
So you have several options left to get rid of your lazy loading problem.
Use shale and write your own shaled datamodel with clear callbacks which
notify the datamodel on when to aquire and drop the session and be done
with it.
Use JTA and hope that it works as you need it (which I cannot really
assure you since I dont know jta really).
Preload everything you want to display either by tweaking the hibernate
configuration files or doing a manual load of the parts you want to
display within the session scope (which is what I did because I did not
know the shale solution at that time).
Hope, that somebody solves the problem for you in a convenient way,
before the next deadline. Which is very unlikely to happen.
My personal opinion is, that shale might be the best approach for your
problem in the long term. The manual preloading, messing around with the
config files, might be to messy and too error prone in the long run.
