Opensessioninview Hibernate/echo2
Sat, 12/09/2006 - 15:09 — nbarrera
Hi, just wanted to know if someone had already implemented open session in view with echo2...
i d need some advice on which point of the framework i could intercept and open session...
The thing is that i want to treat my mapped objects without minding that there is an orm or a database at all..., except for things like queries to db or storing a new object.
i hear all voices... :) tanks...
Same! Except with JDO/JPOX. Anyone?
I've looked through the source and not found an obvious place to hook into the request processing labyrinth.
I've encapsulated 'Exposed Model' (see "POJOs in Action", Chris Richardson) functionality in an object called 'ModelExposer' which I then attach to my ApplicationInstance. ModelExposer has a ThreadLocal which needs to be associated with the current thread prior to processing each request and then dissassociated when the request processing has completed.
It would be great if ApplicationInstance had two 'hook' methods to allow notification by way of overriding these proposed lifecycle methods:
public void ApplicationInstance.preProcess() {}
public void ApplicationInstance.postProcess() {}
which, if overridden in a derived ApplicationInstance, are called before and after all the processing takes place respectively.
In the meantime would processQueuedTasks() be an appropriate candidate to override to achieve what I want to do?
I've answered my own question:
I've created what seems like a very clean solution for this type of application instance activation/deactivation notification desirable for JPOX/JDO users (and should work for Hibernate equally as well) that want to hook into the request processing cycle to do things like begin/commit transactions, persistence managers etc.,
The changes are all local to one class: ApplicationInstance and are very simple. I've compiled and tried this and it works like a bought one (that's funnier that it sounds when talking about an open source framework!).
Basically I enhanced the static void setActive() method slightly to call notification hook methods activate() and deactivating() on the applicationInstance parameter. You can override these methods in your derived ApplicationInstance class so as to be notified of when the application is being activated and deactivated in each browser request processing cycle. They are not abstract methods so overridding them is not mandatory for those apps that aren't interested in such notification.
[Hint: don't do too much in your ApplicationInstance's constructor because the application isn't activated at that time. Wait till init() to do all your serious stuff because the app will be active by then.]
public static final void setActive(ApplicationInstance applicationInstance) { if ( applicationInstance != null ) { // activates then notifies activeInstance.set(applicationInstance); applicationInstance.activated(); } else { // notifies existing active instance that it is deactivating then deactivates ApplicationInstance deactivatingInstance = (ApplicationInstance)activeInstance.get(); if ( deactivatingInstance != null ) deactivatingInstance.deactivating(); activeInstance.set(applicationInstance); } } /** * Called when an application has just been activated - override this to be notified when your application is about to * process requests */ protected void activated() { } /** * Called when an application is about to be deactivated - override this to be notified when your application has finished * processing requests. Note present tense - deactivatING - application is not yet deactivated ie., getActive() will still return a valid * ApplicationInstance so you can still call methods that use getActive(). */ protected void deactivating() { }It would be great if this code could be added to the main source. I haven't got revision control access but if someone who does could incorporate these small changes it would be most appreciated!
Wouldn't ServletFilters help you do the same?
The approach I use is to use DAO's to fetch/modify/create the objects. The DAO's take care of initialising/closing session etc (there is some overhead here that can be optimised). A sample combination looks something like:
public class Model { private long primaryKey; private String uniqueId; private User user; } public class ModelDAO { public Model get( long primaryKey ) public Model getByUniqueId( String uniqueId ) public Collection<Model> getByUser( User user ) } public class View extends Component { // Better handled in a controller public void someMethod( long id ) { Model model = ModelDAO.getInstance().get( id ); bind( model ); } }I have used the same approach to deal with PL/Java, JDO (ObjectDB and JPOX) and Hibernate with absolutely no code change required in either view or controller. You can easily swap the ORM system you use without worrying about where to change your view/controller.
I don't think so. They 'hook in' before the Echo2 internals get a chance to look at the session and establish which is the current/active ApplicationInstance. I like associating my additional 'per session' objects with the ApplicationInstance because there's already a 1-to-1 relationship there. Portions of the code using these 'per session' objects are only executable once the ApplicationInstance has been activated. eg., a persistence framework object that might wrap the request processing within a begin/commit transaction envelope.
ApplicationInstance is already nicely sessionized so rather than managing the sessionizing of my own per session objects I just have references to them from the ApplicationInstance.
The other constraint is that some of these objects are in the 'model' portion of the MVC architecture and so should not reference directly or know about the existence of ApplicationInstance (ie., a non elegant way would be for them to use ApplicationInstance.getActive() but that breaks the MVC and means those classes now have a dependency on Echo2 which they shouldn't need to have.
I've achieved the same persistence technology independence using Chris Richardon's exposed model pattern but without the need to write any DAOs (which in the case of my object model means there's about 75 DAO classes I didn't have to write!). He uses the concept of services and repositories to encapsulate the persistence technology dependent code and hide it from your model objects - so with a decent ORM like JDO/JPOX your model objects are true POJOs - not one persistence specific code in any of them - in fact the objects themselves don't even know that they are persistent. This makes for an excellent opportunity to make mock services and mock repositories to use during development - that don't read or write to the database so they're lighting fast to test.
In my current object model I've been able to get away with only 1 service class and 1 repository class - which sure beats writing 75 DAO classes.
We were so impressed with the productivity of the exposed model approach that we enhanced our Javelin tool to facilitate the creation of service and repository classes so it's a snap to develop object models and persiste them via the exposed model architecture.
If you haven't got a copy of 'POJOs in Action' I reckon you stop what you're doing right now, jump in your car and go and grab one ;-) - I don't know Chris personally - but I couldn't put his book down for about 2 days when I bought it and read it virtually cover to cover about this time last year. He is very thorough in his coverage of a whole lot of popular persistence architectures: EJBs, JDO, Hiberate, direct JDBC and 'exposed model'. Without directly 'dumping' on EJBs he lays all the facts on the line and you're left wondering why anyone in their right mind would touch them with a 10ft barge pole - but you knew that already! He also questions the value of the DAO approach in light of the productivity, flexibility and 'natural' object modeling that exposed model architecture gives you.
The other thing you'll like about the exposed model approach is that you don't have to write code like that below to access your model objects:
public class View extends Component { // Better handled in a controller public void someMethod( long id ) { Model model = ModelDAO.getInstance().get( id ); bind( model ); } }You just store a reference to your model object in your Echo2 component:
public class View extends Component { protected Company company; // most likely passed in during construction public void addViewComponents() { // Add a label that shows the company name add(new Label(company.getName())); // Add a list containing the names of the employees add(new List(new ListModel(company.getEmployees().toArray())); } }Cool, I will check the book out. It brings a few questions to mind though:[*]Does it support multiple data stores?[*]Can you implement custom caches easily?We have our data spread out across 2 ObjectDB databases (JDO) and 1 Oracle database (Hibernate) (not always mutually exclusive). Depending upon the context we can have the same object being fetched from any of these data stores. In addition DAO's allow us to easily implement custom caches that far outperform any freely available caching engines.
Hi all,
I do not understand every things you speak about.
Using DAO seems to be a common way to resolve my problem,
session is injected or managed by the DAO itself, but what is the effect
when you have a lot of objects displayed in a table like PageableSortableTable. If there is lazy mapping, you can not load every
object completely to be sure the session will not be closed when you will access it !
So I in my mind you have to be sure an object can be detached and reattached every time you need no ?
Is Spring a simple way to do this ?
I tried to create a minimal project using spring echo2 and hibernate (like hse) but without the screen managment. A project like the "single form project" wizzard from Echo2Plugin but with hibernate managed by spring but I could not achieve this.
If somebody can help me to do this it would be very very great !
So far I haven't had to implement a detach/reattach mechanism. If I keep the JDO PersistenceManager alive whilever a user session is alive then I should never need to detach/reattach. The only time I would need this is if I had a clustered environment where sessions could be moved from server to server but if I ever need a clustered environment I'll set up server affinity so my sessions stay on the server they were created on and so never need to get serialized. The only other time a session might need to be serialized and hence would need detach/attach is when the server resources are low - probably cheaper to buy more RAM than spend time developing detach/attach code. (with JDO detach is automatic when objects are serialized so I strictly speaking I would really only have to worry about the attach side of the issue).
Wow, that sure is an interesting problem you have to deal with! It's a pity you can't migrate all the data to a single ObjectDB database. That would make life a lot simpler.
Ok I see that you have a good knowledge of the persistence mechanism.. So let me please ask you some question.. You use JDO with a PersistenceManager hooked if I understood, to the user space (Application).
I tried to do something similar with hibernate, but I have exceptions, if multiple users manipulates the same object or if I recall the same ibject more than one time.. Exceptions like "This object is allready in the session" or something like that.
I am not sure how I have to implement the sessionFactory, to have a "multi-user safe" application.
Have you some recommendations or an example ?
Thank you very much for your help
Dun
We have to have multiple databases purely for better resource management. Putting everything into a big ObjectDB database would be the ideal scenario, but it is not easy to scale (although performance of ObjectDB is close to unbelievable for a lot of things). We also need "enterprise quality" storage for sensitive transactional data which goes into Oracle. I could not get ObjectDB (JDO 1) and JPOX (JDO 2) to coexist in any reliable manner, so had to go in for Hibernate. I could have tried JPOX 1.0 versions, but decided that it would probably end up wasting more time.
For those of you who have never experienced the sheer pleasure of working with a pure object database with no ORM nastiness, I would strongly recommend you try it at least once. We saw performance improvements for general querying of the order 45x to 200x (yes times not percent despite the fact that ObjectDB 1.x is single threaded like HSQL) over MySQL or Oracle. Write performance is not all that great though. A small ObjectDB running off a RAM disk for the most commonly accessed objects, a full ObjectDB for general use and Oracle for transactional persistence gave us the best performance we could get without having to invest in huge server farms. Marry that with liberal use of Lucene to implement custom queries and you have a system that flies. It is a little complex, but it keeps our programmers and system administrators happy :D
We have never needed to deal with attach/detach. We decided to pool PersisitenceManager instances in our PersistenceManagerFactory. This way the PM's are never really closed unless a particular PM has not been accessed for a long time (configurable both in terms of releasing them and time interval). This helps us keep all persistence logic within our persistence API and make it transparently usable from desktop applications, web applications and background processes. Each application session ends up getting bound to a particular PM since most requests to the DAOs are made with existing PersistenceCapable objects which are already bound to a PM. If no PM context is available we fetch another one from the pool. JSF/Struts applications usually end up with no long running PM in use, since they usually work off retrieving objects by primary key or running queries. Echo2/Swing/Background applications OTOH end up usually with a PM instance bound by context to the application session.
Unfortunately Hibernate calls their peristence manager a session which causes a bit of confusion. In JDO it's called the PersistenceManager. The way I work it is that I have a persistence manager for every (Servlet/Echo) session. So you would have to have a separate Hibernate session for every session - if you know what I mean.
You can't attach the persistence manager (session) to the servlet itself because the servlet instances can be shared around and allocated to a different thread with each HTTP request.
What you need to do is attach the persistence manager (session) to the ApplicationInstance when you create a new one for a user, then each time a request comes in for that application instance you need to associate your persistence manager with that thread so that you can access it via ThreadLocal in your code.
I have actually created a ORM independent framework for doing just that. It abstracts all of the JDO and Hibernate specific concepts so that you can use it to with JDO or Hibernate without changing any of your model objects or UI code. It currently supports JDO but all the Hibernate specific implementation classes are there - they just need a Hibernate developer to fill in the gaps - probably only about max 15 lines of code!
I've been thinking about open sourcing it because it makes the above work really nicely with hardly any coding.
Yes it would be good if ObjectDB worked with JDO 2 (or does it now? It didn't a while back).
I've been using JPOX (JDO 2) for some time now and am very impressed. My early ORM work was with Hibernate but I shifted to JPOX for a number of reasons.
I've heard that they're fast! JPOX now supports the open source database db4o which I believe would be a killer combo.
There is no doubt that some time in the future most of us will be storing objects in object databases (heh sounds like that's where they belong heh!?) so that's why I'm sticking to solutions like JDO which are capable of supporting both RDBMSes and OODBs so I can switch over to a OODB without any code changes and get the mega performance gains.
It would be a great contribution !!! I am searching for implement this for a long time now. And it seems to be exactly what you developped.
Please keep us informed if you decide to share this work.
Thank you very much fir the others explanations, I will work with a better java developper than me to try to apply theses best practicies.
Cheers,
Dun
It is not official yet. ObjectDB 2 (alpha stage) is built to JDO 2 standards. In addition they have a completely rewritten query engine that they claim will be faster (I can't wait to see how much) and less buggy. ObjectDB 1.x query parser had some bugs when dealing with join queries. The new version will be multi threaded as well.
I had tested ObjectDB and db4o before deciding on ObjectDB. ObjectDB was faster and was built around an open standard. JPOX did not have db4o support at that point.
Golfman, I will be solving the same problems that you described above using Hibernate. If you'd like me to check out and apply the Hibernate specific stuff to your code pass it my way.
That would be great. Thanks. I'm just doing some final clean up before it goes public.
You've come to the right forum topic! If you have followed some of these posts you'll see that the "Exposed Model Pattern" is exactly what you want to have model objects that have no code at all to make them persistent.
We've just released an open source "exposed model framework" which is elegent in it's simplicity. The core is made up of only 6 classes so it's pretty easy to pick up and learn. It goes a long way to help you provide open session (Hibernate) or open persistent manager (JDO) in view without having to write any ORM or database specific code except in your class that contains your queries (called the Repository in Exposed Domain Model speak).
The JDO implementation classes are implemented and tested. JamoSmith on this forum as offered to do some work on the Hibernate implementation - which should be fairly easy.
The library is called exPOJO and can be found at http://www.expojo.com
I'd be interested to here any feedback you have on the library.
I've finished cleaning it up over the last day or so and I'm glad to say that exPOJO is ready to go!
http://www.expojo.com
Let us know if you have any questions.
I have found the code below a necessary addition to the ApplicationInstance class in order to use the popular "Open Session In View" and "Open PersistenceManager in View" patterns with Echo2 when I attach the "Session (Hibernate session - misleading term I know)" or PersistenceManager (JDO) to the ApplicationInstance during its construction (ie., not using spring framework).
The Session/PersistenceManager then stays with the ApplicationInstance for its entire lifecycle. I could manage it as a separate session value myself and override the servlet's service method to provide the hooks but there is a range of ApplicationInstance lifecycle and resynchronization issues that I have to code for to do this. It's much more convenient to establish a 1-to-1 relationship between my ApplicationInstance subclass and the Session/PersistenceManager which automatically ties their lifecyles together.
I have achieved my aim via what turns out to be a very simple modification to the ApplicationInstance class but I have to keep adding the code below manually each time I download the latest Echo2 code base.
What process is involved in getting it to be incorporated into the code base? It's just classic simple 'hook' mechanism whereby any subclass can override the new activated() and deactivating() methods to be notified of changes in the 'active state' of an application and thereby perform tasks like associate the PersistenceManager (JDO) or the Session (Hibernate) with the current thread that is servicing the session's request and perhaps wrap the request processing within a transaction.
public static final void setActive(ApplicationInstance applicationInstance) { if ( applicationInstance != null ) { // activates then notifies activeInstance.set(applicationInstance); applicationInstance.activated(); } else { // notifies existing active instance that it is deactivating then deactivates ApplicationInstance deactivatingInstance = (ApplicationInstance)activeInstance.get(); if ( deactivatingInstance != null ) deactivatingInstance.deactivating(); activeInstance.set(applicationInstance); } } /** * Called when an application has just been activated - override this to be notified when your application is about to * process requests */ protected void activated() { } /** * Called when an application is about to be deactivated - override this to be notified when your application has finished * processing requests. Note present tense - deactivatING - application is not yet deactivated ie., getActive() will still return a valid * ApplicationInstance so you can still call methods that use getActive(). */ protected void deactivating() { }Correction: the support for the Hibernate persistence engine has just been implemented. If you would like to test it please download the expojo.zip (<180k) and give it a run.
http://www.expojo.com
Let us know if you have any questions.
Hi golfman !
First ! Thank you very much for you contribution.. Your expojo seems to be exactly what a lot of us want for Echo2.
Now my question is.. Do I need to make your modification on ApplicationInstance to use expojo ?
If I understood the expojo system. I need to add a ModelExposer object to my ApplicationInstance, and then ?
Do you have a mini app as sample ? or a little tutorial ?
Maybe golfman do not have the time to write these tutos but if someone could create a echo2 project using hibernate persistence and expojo and can show us how.. It would be very very cool..
Thank you for your job.
Dun
Good to hear! I certainly needed something like expojo myself and couldn't work out why something like this wasn't already available - anyway, it is now!
Strictly speaking you don't have to but it's a heck of a lot easier if you do. If you don't then you have to override the service method in the servlet and then create a ModelExposer when a session is first created and then you have call modelExposer.attachThread() at the start and modelExposer.detachThread() after super.service() has been called.
As this type of session management is already being handled by ApplicationInstance it's a lot easier if you just take advantage of that by getting your ApplicationInstance to store a reference to your ModelExposer -and then your MyApplicationInstance.activated() calls modelExposer.attachThread() and your MyApplicationInstance.deactivating() called modelExposer.detachThread(). It would be great if these methods could be added to the Echo2 code base so they can be overridden in our derived classes.
Yes, that's the nice way to do it. Would be nice if the Echo2 gods saw fine to enhance the ApplicationInstance superclass as defined in this thread.
Golfman (me) could have the time to write a JDO/JPOX sample app as he uses that almost exclusively but once that is written it would be very easy for a Hibernate developer to contribute a Hibernate example by porting the JPOX version to Hibernate - especially as expojo hides all of the persistence library specific code from your pure, clean POJO domain model. I'll see if I can get a sample Echo2/JDO/expojo app together in the next few days.
Nemo problemo!
Hi, Golfman...
i don't know a thing about jdo and persistence managers... but as you say that they 're very similar to Hibernate's Session so i got the next question...
you 're storing the PM o Session in the HttpSession object (or let's say the ApplicationInstance)... so obviously you don't need to reattach objects... but isn't that approach kind of resource consuming?... hibernate has the first level cache in the Session object so although i disconnect the session before i store it so that i do not spent a database connection many objects will be saved in the httpsession, as many as i 've bring from the disk storage in that request...
perhaps that has some performance or resoureces issues that you may be overlooking...
perhaps you can explain me why...
as i 'm trying to avoid those issues, and i 'm stucked tyring to reattach objects.
Although your way is simpler i 'm afraid of spending too many resoureces...
It may be a performance issue in certain scenarios but that is not guaranteed - in fact in many cases it can be a performance boost!
Imagine if your server didn't have to load all those objects from disk each time you got a HTTP request because they were already in memory (physical or paged)? If you get lots of requests and your PC has enough virtual memory to handle all of your current requests then why throw away all of your cached objects after each request?
This is especially important in AJAX environments such as Echo2 where there are now many, many more HTTP requests per user session (user session not Hibernate session!).
Remember - the Hibernate cache is a cache - it should intelligently throw away cached objects if resources become limited. You shouldn't assume that you need to throw away everything after each request is processed. That may be seen as innefficient use of resources if you didn't really need to.
Just make sure that you have a huge virtual memory page file and you should get away with holding onto all of your cached objects in the JDO PM or Hibernate Session. Dormant sessions will have their PM/Session cached objects paged out to disk reducing any strain on physical memory. Accessing those again when required from virtual memory written to disk will be 50x faster than performing queries to retrieve them as rows and then synthesize them into objects again - which would happen if you had blown away your cache.
Then sit back and enjoy all that time you saved by not having to hack your code full of all those detach/reattach calls....
...then later down the tack if you have a performance problem tell your boss that with all the money he saved by you not having to write all that detach/reattach code he can afford to by a few new memory sticks for the server! ;)
I got your point, but unfortunately boss isn't always happy 'bout hearing such things from us..., :) although in some cases as you mentioned above it's cheaper to buy a new stick...
but well... in my particular scenario we 'll most probably have some other apps in the same server as the web app... (so imagine I suggeset buying new memory... i should say first, buy a new server...) and thinking about user (http) sessions growing rapidly just scares me...
despite of thinking that your approach is much more convinient... i 'll try to reattach objects just to be sure there 're no mem leaks. Perhaps with some benchmarking i 'd change my opinion :D
c ya...
thanks!
Us programmers are always looking for problems - sometimes ones that aren't even there. More recently I've taken some lessons from the Extreme Programming Pocket Guide that I bought a while back - "don't solve problems until you're sure you need to", "do the simplest thing that will work first and then move up from there if you have to". This goes againsts my 20 years of software ENGINEERING in which the aim of the game was to OVERENGINEER everything from the start so you end up solving problems you IMAGINE might or *could* exist and often 70% of the over engineering effort may never have been needed. I'm sure that's useful when writing software for the space shuttle but when I'm writing a web app it's more important to get something working now rather than have something that *might work perfectly* in 2 years time.
Tell your boss to grab a book on eXtreme Programming (XP) and hopefully he'll see things your way and buy a few more memory sticks if he's still doubtful ;)
Hi All,
Thoses two hooks in ApplicationInstance (activated and deactivating) are really usefull dealing with things such as persistance services. Is it possible to have a confirmation from NextApp guys around here that something similar or just thoses two hooks could make their way mainstream in the near future ?
Regards
Paul
Echo2 Binaries with Activate/Deactivating mods
It seems like lots of people are having the same need for OpenSessionInView (Hibernate) and OpenPersistenceManagerInView (JDO) that caused me to add those hooks to my ApplicationInstance class in the first place.
Hopefully these changes will make their way into the main Echo2 source and binary distributions eventually but in the meantime I've decided to make a prebuilt version of the Echo2 library with these mods included so that everyone who want's the benefit of these hook methods can have them without having to download the source themselves, making the mod and then compiling.
I've created a zip with the Echo2 binaries (.zip) and included the source for modified ApplicationInstance.java file. You can download it from the expojo.com site:
http://www.expojo.com
The download link (Download Echo2 ActDeactMod) is on the first page towards the bottom.
I think I've complied with all the Echo2 open source licensing terms by providing the source code for the modification within the distribution and including the license files. If I've neglected anything in my compliance please let me know and I'll rectify it.
Golfman,
Did you consider adding these hooks as subscribable events instead of methods to override? I might want to add more listeners for applications becoming active and deactivating. Maybe that doesn't really make any sense. :)
These are certainly useful ...
Cheers,
Mojo
I didn't think of that but I was trying to add something that made minimal change to the Echo2 source to make it easier for the developers to merge the changes in. The initial need is for the application instance itself to know of its own activating/deactivating state changes - I don't know of any other objects that might want to be notified of this but, like you say, there could be other notification needs now or some might arise in the future...
... but if I catered for those perceived needs then I'd be breaking some of the policies in my cute little XP pocket guide I've just read:
"Do the simplest thing that could possibly work" and "You aren't gonna need it". I wish the "Extreme Programming Pocket Guide" was around 20 years ago when I started in this game - I reckon I could have got a lot more *useful* work down over these last 20 years!
Now if I had a buck for every class or line of code I've written that never got executed in a real system....