Home » Eclipse Projects » Rich Client Platform (RCP) » More Hibernate issues
| More Hibernate issues [message #466770] |
Tue, 24 April 2007 15:59  |
 No real name
Messages: 38
Registered: July 2009 |
Member |
|
|
Well now I've done it... My RCP application is becoming popular with
users and they're running it on multiple machines in an office all
connected to the same DB via Hibernate (two-tier architecture).
My RCP application architecture:
1) Multiple levels of control -- lowest level contains domain model
objects and business logic on them -- no UI stuff. This level is also
used by a Spring-based web application. works great.
The next level contains listeners and access to the low level domain
model objects. When domain model objects change, various listeners fire
to update the UI.
2) The main perspective includes a treeViewer view of the data model.
It also contains actions for the usual create, delete, edit operations
on these objects. This treeViewer view is basically active all of the
time and the source of all user operations. Sort of like the Package
Explorer view in the Eclipse IDE.
3) All Hibernate objects are lazy-loaded. As the user clicks on an
object in the tree and expands it to see its children (e.g., like
opening a directory, Hibernate hits the DB to retrieve the children
(when accessed by the workbench adapter classes).
Now, when multiple, concurrent applications are connected to the DB and
mutating the object model, I'm getting the expected '
org.hibernate.StaleObjectStateException: Row was updated or deleted by
another transaction'.
Bruce Alspaugh wrote late last year:
"What I recommend is that you use the session per application
transaction pattern. Create a class called a Form that consists of an
editor and its related views such as validation problems or a progress
view. Each form would have it's own independent session. Each form
would also have it's own dirty state corresponding to the dirty state of
that session. If an exception is thrown, you only have to close out that
individual form."
But how can I use that in my tree viewer which is basically 'up' all of
the time and from which users perform their various actions?
|
|
|
| Re: More Hibernate issues [message #466786 is a reply to message #466770] |
Wed, 25 April 2007 07:28  |
Sebastian Fuchs
Messages: 97
Registered: July 2009 |
Member |
|
|
Maybe you're interested in this thread:
http://forum.java.sun.com/thread.jspa?threadID=700590&st art=45&tstart=0
It does not solve your problem but shows that you are not alone.
For me it turned out, that Hibernate can't be used efficiently in a
multiuser-application with long living objects.
Haven't found any solution yet, all my hopes are set to
www.eclipse.org/proposals/eclipselink
Sebastian
RacerNewbie schrieb:
> Well now I've done it... My RCP application is becoming popular with
> users and they're running it on multiple machines in an office all
> connected to the same DB via Hibernate (two-tier architecture).
>
> My RCP application architecture:
>
> 1) Multiple levels of control -- lowest level contains domain model
> objects and business logic on them -- no UI stuff. This level is also
> used by a Spring-based web application. works great.
>
> The next level contains listeners and access to the low level domain
> model objects. When domain model objects change, various listeners fire
> to update the UI.
>
> 2) The main perspective includes a treeViewer view of the data model. It
> also contains actions for the usual create, delete, edit operations on
> these objects. This treeViewer view is basically active all of the time
> and the source of all user operations. Sort of like the Package
> Explorer view in the Eclipse IDE.
>
> 3) All Hibernate objects are lazy-loaded. As the user clicks on an
> object in the tree and expands it to see its children (e.g., like
> opening a directory, Hibernate hits the DB to retrieve the children
> (when accessed by the workbench adapter classes).
>
> Now, when multiple, concurrent applications are connected to the DB and
> mutating the object model, I'm getting the expected '
> org.hibernate.StaleObjectStateException: Row was updated or deleted by
> another transaction'.
>
> Bruce Alspaugh wrote late last year:
>
> "What I recommend is that you use the session per application
> transaction pattern. Create a class called a Form that consists of an
> editor and its related views such as validation problems or a progress
> view. Each form would have it's own independent session. Each form
> would also have it's own dirty state corresponding to the dirty state of
> that session. If an exception is thrown, you only have to close out that
> individual form."
>
> But how can I use that in my tree viewer which is basically 'up' all of
> the time and from which users perform their various actions?
|
|
| |
| Re: More Hibernate issues [message #466939 is a reply to message #466935] |
Thu, 26 April 2007 17:33 |
Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
On Thu, 26 Apr 2007 09:59:09 -0500, RacerNewbie wrote:
> I'm sleeping muuuuch better these daze now that I have this problem
> solved......
>
>>
You really did not say how you solved the problem.
|
|
|
| Re: More Hibernate issues [message #466967 is a reply to message #466939] |
Thu, 26 April 2007 18:31 |
No real name
Messages: 38
Registered: July 2009 |
Member |
|
|
Okay,
More details:
-2) My application follows (very closely) the application design pattern
outlined in Chapter 8 of the Hibernate in Action (Writing Hibernate
Applications).
I also have a Facade class with static methods to perform all of my CRUD
actions on the objects n includes various 'finder()' methods. This
class is accessed by adapters, action classes, editor input classes,
etc. vs. the DAO methods.
-1) The basic pattern is to not use long-lived Hibernate sessions. Once
my app fires up I close the Hibernate session. Basically, whenever I
need to read, edit, delete an object, I refetch the object from the
database. All of the routines that perform object manipulation are
passed the object (or easily retrieved from the IStructuredSelection
selection). Then, at the end of the routine that performs these actions
I close the Hibernate session.
0) Implement hibernate object versioning. Look at:
http://www.hibernate.org/hib_docs/v3/reference/en/html_singl e/#mapping-declaration-version
1) The routine I modified here was IWorkbenchAdapter.getChildren(). I
cut down on DB hits by using the object version technique referenced above.
2) Same pattern here in the 'run()' method. Refetch the object at the
beginning and close the Hibernate session at the end.
3) you get the picture.....
RacerNewbie wrote:
> The new pattern I use actually consists of three patterns:
>
> 1) The workbench adapters to fill the tree viewer views. These adapters
> are hit *a lot*. I've implemented a simple object caching technique
> using the object version facility in Hibernate. Works nice.
>
> 2) the action routines that create, edit, or delete objects from the
> Hibernate model. These are triggered from user actions on the tree
> viewers.
>
> 3) The editors that edit blobs of data from the object model. I'm not
> quite done with this pattern, but will finish w/in the day.
CL 'dnoyeB' Gilbert wrote:
> On Thu, 26 Apr 2007 09:59:09 -0500, RacerNewbie wrote:
>
>> I'm sleeping muuuuch better these daze now that I have this problem
>> solved......
>>
>
>
> You really did not say how you solved the problem.
|
|
|
| Re: More Hibernate issues [message #467044 is a reply to message #466967] |
Fri, 27 April 2007 13:23 |
| Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
On Thu, 26 Apr 2007 13:31:37 -0500, RacerNewbie wrote:
> Okay,
>
> More details:
>
> -2) My application follows (very closely) the application design pattern
> outlined in Chapter 8 of the Hibernate in Action (Writing Hibernate
> Applications).
>
> I also have a Facade class with static methods to perform all of my CRUD
> actions on the objects n includes various 'finder()' methods. This
> class is accessed by adapters, action classes, editor input classes,
> etc. vs. the DAO methods.
>
> -1) The basic pattern is to not use long-lived Hibernate sessions. Once
> my app fires up I close the Hibernate session. Basically, whenever I
> need to read, edit, delete an object, I refetch the object from the
> database. All of the routines that perform object manipulation are
> passed the object (or easily retrieved from the IStructuredSelection
> selection). Then, at the end of the routine that performs these actions
> I close the Hibernate session.
Yes, definitely. Keep open the session factory, but use and close the
sessions ASAP. I also use the command pattern for manipulating my
Hibernate objects. This makes all hibernate object manipulation inside a
command so I can catch and handle the hibernate (masked) exceptions in one
uniform way.
>
> 0) Implement hibernate object versioning. Look at:
> http://www.hibernate.org/hib_docs/v3/reference/en/html_singl e/#mapping-declaration-version
>
> 1) The routine I modified here was IWorkbenchAdapter.getChildren(). I
> cut down on DB hits by using the object version technique referenced
> abov
Interesting.
>
> 2) Same pattern here in the 'run()' method. Refetch the object at the
> beginning and close the Hibernate session at the end.
>
> 3) you get the picture.....
>
Yep, sounds good. This makes conflicts less likely. But still, what
happens when there is one? Or have you eliminated this possibility
somehow?
|
|
| |
| Re: More Hibernate issues [message #467199 is a reply to message #467048] |
Mon, 30 April 2007 19:50 |
| Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
On Fri, 27 Apr 2007 08:54:04 -0500, RacerNewbie wrote:
> I haven't run into any problems - yet..... But give me a few days of
> testing.
>
> You mention 'conflicts'. Are you referring to some specific concurrent
> DB access issue? I've not hit my new code hard enough with this use
> case yet.
>
> The Hibernate issues I was seeing include:
> - StaleObjectStateException
> - LazyInitializationException (accessing a collection from an object in
> a different session)
>
> I'm a bit concerned with my solution for the workbench adapters when
> filling the tree viewer of my object graph data. These are called *a
> lot*. Did I say they were called *a lot*?
>
> My simple object versioning technique, while helpful, is not enough to
> cut down on the DB hits from these methods..... I may have to implement
> YAC -- yet another cache.....
>
Right, thats what I am thinking. I basically cache each hibernate object
indefinitely. I am going to implement a refresh at some point. But since
I never know if I have the latest, there is really no point in trying to
get it. Either I implement a scheme to ensure I have the latest, or just
don't bother. Currently I don't bother. But like I said, Ill add a
refresh soon enough.
|
|
|
Goto Forum:
Current Time: Sat Apr 20 02:04:04 GMT 2024
Powered by FUDForum. Page generated in 0.03331 seconds |
] 
Search
Help
Register
Login
Home
