Hi, I understand that SelfServicing does not support FastSerialization (I hope it will once though). But when I set this flag in global.asax - Application_Start

SD.LLBLGen.Pro.ORMSupportClasses.SerializationHelper.Optimization = SD.LLBLGen.Pro.ORMSupportClasses.SerializationOptimization.Fast;

and turn on SessionState server (so that the serialization occours), it cannot deserialize LLBL entities from session (serialization works ok).

There is no adapter entity in the project, just selfservicing.

LLBL ver: 2.5 asp.net ver: 2.0 VS: 2005 SP1

PS: Fast serialization would be great also for SelfServicing exactly for this purpose. When the entities are serialized to/from session, it takes very long time and a lot of resources are used. Fast serialization would make me veeery happy

You should use the Adapter model for the Distributed Systems.

Anyway the following are general tips for designing Session objects:

When designing your session object model, avoid storing object types in the session. Instead, only store primitive types in the session dictionary and rebuild your business layer session objects on every request based on the session data. This avoids the overhead of using BinaryFormatter.

If you are storing a lot of different data items in the session, it's better to flatten your data into many separate session entries instead of grouping them into a single item by placing them in a class or single buffer. This enables more granular access to the needed items, and enables the application to take advantage of on-demand deserialization of needed data for session accesses. It also minimizes the number of data items that need to be serialized again if some are changed during request execution.

You should use the Adapter model for the Distributed Systems.

It is not distributed system. It is plain web application (flight ticket reservation system). It uses common model 1. search a lot of data from reservation systems and store them in session 2. let the user choose the flight she wants 3. make reservation

I can not persist all the data in SQL for every search a user does. So i keep it in session memory.

Thanx for general suggestions anyway.

it cannot deserialize LLBL entities from session (serialization works ok).

Do you receive an exception? If so please post it here with the stack trace.

Also, which LLBLGen Pro runtime library version are you using? (consult: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7717)

Selfservicing won't get this code as it's not exactly that simple to implement it. True, asp.net applications could benefit from it, though you could also opt for other strategies to make things faster. In general one should fetch as less data as possible. Having a big entity set in hte datasource control isn't useful in a lot of cases, as most data isn't viewed on the page, otherwise the page would be very big as well.

Hi,

SD.LLBLGen.Pro.DQE.SqlServer.NET20.dll : ver. 2.5.7.906 SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll : ver. 2.5.7.1119

The exception is standard

Unable to serialize the session state. In 'StateServer' and 'SQLServer' mode, ASP.NET will serialize the session state objects, and as a result non-serializable objects or MarshalByRef objects are not permitted. The same restriction applies if similar serialization is done by the custom session state store in 'Custom' mode.

Stack Trace:

[NullReferenceException: Object reference not set to an instance of an object.]
   SD.LLBLGen.Pro.ORMSupportClasses.CollectionCore`1.GetObjectData(SerializationInfo info, StreamingContext context) +151
   SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase`1.GetObjectData(SerializationInfo info, StreamingContext context) +25
   System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitSerialize(Object obj, ISurrogateSelector surrogateSelector, StreamingContext context, SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter, ObjectWriter objectWriter) +281
   System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.Serialize(Object obj, ISurrogateSelector surrogateSelector, StreamingContext context, SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter, ObjectWriter objectWriter) +50
   System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(WriteObjectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo) +411
   System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck) +489
   System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph, Header[] headers, Boolean fCheck) +131
   System.Web.Util.AltSerialization.WriteValueToStream(Object value, BinaryWriter writer) +1513

[HttpException (0x80004005): Unable to serialize the session state. In 'StateServer' and 'SQLServer' mode, ASP.NET will serialize the session state objects, and as a result non-serializable objects or MarshalByRef objects are not permitted. The same restriction applies if similar serialization is done by the custom session state store in 'Custom' mode.]
   System.Web.Util.AltSerialization.WriteValueToStream(Object value, BinaryWriter writer) +1602
   System.Web.SessionState.SessionStateItemCollection.WriteValueToStreamWithAssert(Object value, BinaryWriter writer) +34
   System.Web.SessionState.SessionStateItemCollection.Serialize(BinaryWriter writer) +627
   System.Web.SessionState.SessionStateUtility.Serialize(SessionStateStoreData item, Stream stream) +257
   System.Web.SessionState.SessionStateUtility.SerializeStoreData(SessionStateStoreData item, Int32 initialStreamSize, Byte[]& buf, Int32& length) +60
   System.Web.SessionState.OutOfProcSessionStateStore.SetAndReleaseItemExclusive(HttpContext context, String id, SessionStateStoreData item, Object lockId, Boolean newItem) +87
   System.Web.SessionState.SessionStateModule.OnReleaseState(Object source, EventArgs eventArgs) +355
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

In general one should fetch as less data as possible. Having a big entity set in hte datasource control isn't useful in a lot of cases, as most data isn't viewed on the page

The problem is, when you need little data, but the structure of the data is too complicated to fetch it every time, it is needed. i.e. to get the country of the city of the airport, which the flight starts from. I managed to implement caching algorithm and in LLBL disabled few relations, so the space required for the entity in memory dramatically decreased. In global I found, that it is better to make all codebook data cached separately and remove relations to them in LLBL

i.e. flight.Airport.City.Country.Name // this is really nightmare - 3 entities are fetched and stored in memory GetCountryName(flight.CodeAirport) // this works just fine, if cached correctly

It helped a lot (less data means faster serialization), but it could be better.

(sorry, did not intend to steal topic, enough for today )

flight.Airport.City.Country.Name // this is really nightmare - 3 entities are fetched and stored in memory

For such cases I'd recommend using another datastructure to keep in the session. Such as a Dictionary, or a DataTable (fetch a DynamicList).

This Forum's code is free for public http://www.llblgen.com/HnD/ There you can find an example of such data structures stored in the Session or Application stores. (eg. as far as I can remember, User Forums Priviledges are stored in a Dictionary in the Session).

For such cases I'd recommend using another datastructure to keep in the session. Such as a Dictionary, or a DataTable (fetch a DynamicList).

The problem is that my structures are a bit more complex than a simple list of data. I use complex relations between entities (which LLBL handles very well).

I though used this approach of creating "compact" versions of LLBL entities in distributed scenario in one project. I created plain data classes in LLBL generator (I modified your templates in LLBL and generated classes that filled themselves from LLBL entities and vice versa - I could post it, if someone needs it). I could use these entities in ASP.NET web services instead of real LLBL entities. This allowed me to create rich good defined interface to my web methods and use LLBL entities as arguments. (normally WSDL creates DataSet types out of LLBL entities)

I don't see it here this simple because if I create this compact copy of LLBL entity I loose all objects references. I could workaround it somehow, but I like it the way serialization do it (it keeps these references).

I know, it is just because I keep to SelfServicing. But for some reason I prefer it to Adapter. With some sense of use it performs at least equally.