Hi Werner, What I would try to achieve with the callback mechanism would be simply to get the reference to the current object, and reattach it to the current session. Please take into account that I'm currently using the OpenSessionInViewFilter pattern from Spring, so the session would be automatically opened and closed in a transparent way.
So the only hit in performance would be the call to Hibernate.lock(object, LockMode.NONE) for each object in each row in the DataModel. If there are many of them, maybe it's worth the effort instead of having to preload everything into memory, without lazy loading it. What do you think? I've been looking at ListDataModel implementation of the DataModel interface, and it could be easily extended with a callback mechanism every time the getRowData is invoked... 2005/6/20, Werner Punz <[EMAIL PROTECTED]>: > 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. > >
