Basically what I have is the following:
* One application that stores data to one database (raw binary data)
* One application that gets data from this database, decodes and
processes it before writing it back to another database.
* The reason for the two databases is that the first application is
made very simple so that it can become "bugfree" while the other is
more complex with possible user extensions with new decoders and
processing algorithms.
* Both these applications is 24/7 applications with data comming in
fairly frequently (every 10-30 seconds)
* So the application I refere to here is the second one
* They will mostly run without user interaction


On 17 Mar, 14:39, Fabio Maulo <[email protected]> wrote:
> Where is the description of the use case?
>
> 2009/3/17 Utopico <[email protected]>
>
>
>
>
>
> > How would you suggest to have the session management pattern?
>
> > On 17 Mar, 14:23, Fabio Maulo <[email protected]> wrote:
> > > 2009/3/17 Utopico <[email protected]>
>
> > > > Ok. Thank you very much.
>
> > > > I guess the second-level cache will not be cleared during this
> > > > process?
>
> > > No man.... not the cache but the session-cache.
> > > BTW change you session management pattern.
>
> > > > On 17 Mar, 14:00, Oskar Berggren <[email protected]> wrote:
> > > > > If you're interested you could have a look at the numbers in
> > > > > ISession.Statistics for an idea about how big your session has
> > become.
>
> > > > > /Oskar
>
> > > > > 2009/3/17 Fabio Maulo <[email protected]>
>
> > > > > > open and close the nh-session for each message/operation.
>
> > > > > > 2009/3/17 Utopico <[email protected]>
>
> > > > > >> In a real application there would be many datasources reporting
> > data
> > > > > >> (at less frequent intervals). So how would you suggest to handle
> > the
> > > > > >> session in this case? A realistic scenario would about 30
> > datasources
> > > > > >> reporting data every 60 minutes.
>
> > > > > >> On 17 Mar, 12:16, Oskar Berggren <[email protected]>
> > wrote:
> > > > > >> > Session is not really meant to be long running. Try creating a
> > new
> > > > > >> session
> > > > > >> > for each "run" or at least clear the sessions cache.
>
> > > > > >> > /Oskar
>
> > > > > >> > 2009/3/17 Utopico <[email protected]>
>
> > > > > >> > > Using same session (at least th. I have now done a bit more
> > > > > >> > > monitoring. And it seems that the CPU and memory load is
> > > > increasing
> > > > > >> > > over time while the actual disc writes does not. Also the
> > > > performance
> > > > > >> > > of the database server does not seem to change when monitoring
> > the
> > > > > >> > > database directly while the application is running.
>
> > > > > >> > > On 17 Mar, 11:07, Ayende Rahien <[email protected]> wrote:
> > > > > >> > > > Are you using the same session? Or creating a session every
> > > > time?
>
> > > > > >> > > > On Tue, Mar 17, 2009 at 11:31 AM, Utopico <
> > > > [email protected]>
> > > > > >> > > wrote:
>
> > > > > >> > > > > I have used hibernate for about half a year, but not with
> > very
> > > > > >> high
> > > > > >> > > > > load. Yesterday I had an application running that slowed
> > down
> > > > > >> > > > > significantly after running through the night (from
> > fraction
> > > > of a
> > > > > >> > > > > second to 10-15 seconds). I am pretty sure that there is
> > > > somthing
> > > > > >> can
> > > > > >> > > > > be done to improve this, or a way to find out what is the
> > > > cause. I
> > > > > >> > > > > need some help with this.
>
> > > > > >> > > > > So for my application
> > > > > >> > > > > * I use NHibernate 2.0.0.GA
> > > > > >> > > > > * Visual studio 2008
> > > > > >> > > > > * FirebirdSQL 2.0
> > > > > >> > > > > * received data every 15 seconds on a serial port which is
> > > > then
> > > > > >> > > > > decoded. This results in:
> > > > > >> > > > >   - check for datatype (cached query through SysCache
> > since
> > > > these
> > > > > >> > > > > values are updated seldom, but checked often) and possible
> > > > > >> addition of
> > > > > >> > > > > new datatype entry (each datavalue has a datatype
> > associated
> > > > with
> > > > > >> it)
> > > > > >> > > > >   - using sequence generator for ID on datavalue and
> > > > dataobject
> > > > > >> > > > >   - insert of a dataobject which has about 120 values
> > > > associated
> > > > > >> as
> > > > > >> > > > > follows (results in one dataobject insert and 120 inserts:
> > > > > >> > > > >        [NHibernate.Mapping.Attributes.Bag(Table =
> > > > "DATA_VALUE",
> > > > > >> > > > > Inverse = true, Lazy = true, OrderBy = "TYPE_ID ASC, IDX
> > ASC",
> > > > > >> Cascade
> > > > > >> > > > > = "all-delete-orphan")]
> > > > > >> > > > >        [NHibernate.Mapping.Attributes.Key(1, Column =
> > > > "REC_ID")]
> > > > > >> > > > >        [NHibernate.Mapping.Attributes.OneToMany(2,
> > ClassType =
> > > > > >> typeof
> > > > > >> > > > > (Nortek.SeaState.Domain.DataValue))]
> > > > > >> > > > >        public virtual IList<DataValue> Values
> > > > > >> > > > >        {
> > > > > >> > > > >            get
> > > > > >> > > > >            {
> > > > > >> > > > >                return this._values;
> > > > > >> > > > >            }
> > > > > >> > > > >            set
> > > > > >> > > > >            {
> > > > > >> > > > >                this._values = value;
> > > > > >> > > > >            }
> > > > > >> > > > >        }
> > > > > >> > > > > * All the above is inclosed in a transaction with
> > ReadCommited
>
> > > > > >> > > > > Would I benefit from batch inserts or any other
> > performance
> > > > trick?
> > > > > >> Or
> > > > > >> > > > > is there some stupid flaw in my way of using hibernate?
>
> > > > > > --
> > > > > > Fabio Maulo
>
> > > --
> > > Fabio Maulo
>
> --
> Fabio Maulo
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to