|
Replies:
6
-
Pages:
1
-
Last Post:
Nov 7, 2008 6:12 PM
by: ido.ran
|
|
|
Posts:
5
From:
Israel
Registered:
11/4/08
|
|
|
|
Long Running Conversation In Windows Application
Posted:
Nov 4, 2008 12:26 AM
|
|
Hi, I've read (most) of your book to get the understanding I need about using NHibernate.
I'm using NHibernate in Windows (WPF) application. I am using, what you are calling, long running conversation. That is, I open a session at the beginning of the application and keep it open as long as the application lives.
My application involve modeling processes which built from list of actions. Each action has send object and a receive object.
I have some problems which I did not find solution for in the book:
Since the session detect any changes the user do, if the user is not in "Process" screen editing the actions of the process, which affect the model (persistent objects). Suddenly, the user see she's need new object (that is object of my application, not .NET object). So she open the "Object" screen (while the other screen stays open) and add a new object.
Now, when she save the new object, the session is flashed and any changes, including those made on "another" conversation in the "Process" screen are now committed to the database.
How can I create seperate conversations? Or how else can I use the Session?
Thank you very much,
Ido.
|
|
Posts:
82
Registered:
12/9/05
|
|
|
|
Re: Long Running Conversation In Windows Application
Posted:
Nov 7, 2008 9:13 AM
in response to:
ido.ran
|
|
Hi,
It it generally not a good idea to have a session opened for the whole lifetime of your application. "Long running conversations" are meant for "application transactions"; for example, when you have a wizard with multiple steps.
So I would suggest that your re-design your application so that a separate session is used for each screen.
In the case where the user changes the "Object" screen, all related/affected screens ("Process", etc.) should be informed so that an automatic or manual refresh is done.
HTH,
Pierre Henri.
|
|
Posts:
5
From:
Israel
Registered:
11/4/08
|
|
|
|
Re: Long Running Conversation In Windows Application
Posted:
Nov 7, 2008 10:55 AM
in response to:
kuate
|
|
Hi Pierre,
Thank you for the answer.
I can re-design my application in that way.
I have another question:
In my application I have several repositories which represent collection of related object. For example Object Repository and Process Repository.
The repositories usually get their items by executing "from Object" HQL query (for Object Repository) and "from Process" (for Process Repository).
Currently I cache the results of those HQL queries.
Is that a good practice? Or should I execute the query every time the repository is enumerated or searched?
Thank you,
Ido.
|
|
Posts:
38
From:
Leeds, UK
Registered:
5/1/08
|
|
|
|
Re: Long Running Conversation In Windows Application
Posted:
Nov 7, 2008 11:51 AM
in response to:
ido.ran
|
|
I'll throw my 2p in!..
Where do you cache your data?
I'd start by running the query every time. You then don't have to worry about stale data issues of moving instances between sessions. The relational database also will have it's own caching going on, and performance should be great without the need for additional caching.
You probably know that NHibernate has 2 caches - 1st and 2nd level. The 1st level cache is always on. There's one 1st level cache per Session, and it's helpful in preventing NHibernate for making unecessary db calls. That should be enough.
Are you noticing problems with the speed of your app? Or does it just feel "weird" reloading the data all the time?
The 2nd level cache is optional. It can be shared between sessions. It's generally considered bad practice to cache data in the 2nd level cache without really good cause, so I'd stay away from it.
|
|
Posts:
5
From:
Israel
Registered:
11/4/08
|
|
|
|
Re: Long Running Conversation In Windows Application
Posted:
Nov 7, 2008 12:52 PM
in response to:
tobinharris
|
|
I'm caching the data in the business logic layer.
I'm not noticing any speed problem, I guess it just a habit (maybe a bad one) to cache the data after loading it from the database. I will stop doing it just because I "used to do it".
I'll give you another question (I first will like to thank you again for the answers).
You suggest that I'll have a session for each screen.
Will it be good to open a session when the screen (or more accurately the screen's model) is created, and then pass that session to each repository. I guess I can use ISessionFactory.GetCurrentSession(), right?
Thank you,
Ido.
|
|
Posts:
82
Registered:
12/9/05
|
|
|
|
Re: Long Running Conversation In Windows Application
Posted:
Nov 7, 2008 1:06 PM
in response to:
ido.ran
|
|
Yes and no... GetCurrentSession() is indeed a nice way to share a session among "repositories". However, the available contexts are related to thread-level separations...
Since I think that all your screens share the same thread, you will have to implement your own CurrentSessionContext that links a session to a screen and make sure that repositories are also linked to (and only used by) a specific screen.
For more details, read chapter 10.
|
|
Posts:
5
From:
Israel
Registered:
11/4/08
|
|
|
|
Re: Long Running Conversation In Windows Application
Posted:
Nov 7, 2008 6:12 PM
in response to:
kuate
|
|
OK, I think I can create such thing using construct similar to TransactionScope of System.Transaction namespace. This way all the usage of a repository inside the scope (inside the call context) of specific screen will use the Session of that scope.
Thank you very much for the help.
I'll continue this thread once I'll implement those changes to write how it worked, and if I need to change something.
There is very little documentation of how to implement Windows application with good separation of concerns. Most of the documentation is about ASP.NET applications in which HttpModule is used to create the session.
Ido.
|
|
|
Legend
|
|
Gold: 300
+
pts
|
|
Silver: 100
- 299
pts
|
|
Bronze: 25
- 99
pts
|
|
Manning Author
|
|
Manning Staff
|
|
