Hi all,

An interesting post from Frans led me here and this is really a sales related q. but I couldn't find a more appropriate place to send it...

I’ve recently been employed to migrate a legacy app into the C#/ASP.NET world, a world I am getting a crash course on, along with ORM (started yesterday, but conceptually I am already a fan . The plan is to go with a completely Sybase db/ntier solution using a browser front end making web services calls.

Load-wise the current web side supports up to 30-40 requests per second before bogging down. The current architecture is 2 web servers -> 1 legacy multi-value db which may request info from another Sybase db. The first stage migration is the web-site, which is the most load-intensive (at an ever increasing rate.. .

I was hoping someone might be able to give their opinion on the following topics/scenarios:

• 1. Given the above load stats do you have any idea how close is this to critical mass on a single server using this framework? A rough idea will be fine, if possible?
• 2. Concurrency is a topic I’m not used to addressing in a stateless manner. I understand there are a various ways of accomplishing this – out of interest which way do you use yourself with this framework?
• 3. Does the LLBLGen support multiple dbs within the one model?
• 4. Is there any update on the Sybase front?
• 5. I like the sound of the hierarchical object loading/saving (and lazy loading). Presumably these multiple db update/inserts can optionally be wrapped within the one transaction? Thanks in advance for any responses to my queries and Frans + team, best wishes with your product.

1. Given the above load stats do you have any idea how close is this to critical mass on a single server using this framework? A rough idea will be fine, if possible?

I think LLBLGen Pro framework have been used in much harder loads.

1. Concurrency is a topic I’m not used to addressing in a stateless manner. I understand there are a various ways of accomplishing this – out of interest which way do you use yourself with this framework?

That's a very general question, and it depends on how do you want to implement concurrency, anyway you may find some useful posts about this subject on the forums, just search for the word concurrency.

1. Does the LLBLGen support multiple dbs within the one model?

If you mean multiple catalogs in the same project, then the answer is yes. If you mean portability to different database types, then the answer is yes too. (you should use the adapter model, and generate the DBSpecific code for each database type)

1. Is there any update on the Sybase front?

The following is the latest news I know about this subject. http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=4482

1. I like the sound of the hierarchical object loading/saving (and lazy loading). Presumably these multiple db update/inserts can optionally be wrapped within the one transaction?

Please refer to LBLGen Pro manual "Using the generated code -> SelfServicing -> Transactions"

Thanks for the quick response Walaa. Sorry if these questions are pretty naive/general, its near the end of ORM day 1.5 for me and I'm still getting upto speed.

I think LLBLGen Pro framework have been used in much harder loads

Thats a good start I was hoping for some actual stats? I realise this will depend on other factors like the system environment + architecture, but it would help me get a vague achievable benchmark that I could realistically aim at. If anyone has a general range out there for a single webserver running LLBLGen then I'd be interested to hear it + the db type?

That's a very general question..

Yes it is, sorry about that. Optimistic locking will suit our needs generally, altho it would be nice to have the flexibility to go pessimistic for certain objects if we find there are too many conflicts... how easy is it to do this using your framework? (ie. does it require manual coding, or is it implemented during object setup)

I'm thinking about using the row/timestamp-style, but using an integer VersionNo property/field since my directive has been "make it db non-specific" . I would be interested in any elses thoughts tho. Especially on how they handle a hierarchical object, where say one of its children objects fail to pass a concurrency test...

...the answer is yes

Ok tentative "Yay!" I'll become more familiar with your framework + terms before posting more on this one.

The following is the latest news I know about this subject.

Right, I was hoping there might have been some movement since then.

Please refer to LBLGen Pro manual "Using the generated code -> SelfServicing -> Transactions

Willdo.

Jamanga wrote:

Thanks for the quick response Walaa. Sorry if these questions are pretty naive/general, its near the end of ORM day 1.5 for me and I'm still getting upto speed.

I think LLBLGen Pro framework have been used in much harder loads

Thats a good start I was hoping for some actual stats? I realise this will depend on other factors like the system environment + architecture, but it would help me get a vague achievable benchmark that I could realistically aim at. If anyone has a general range out there for a single webserver running LLBLGen then I'd be interested to hear it + the db type?

We've done our own profiling and we've tried to eliminate as much roadblocks as possible in fetch and save logic. Comparing the speed with for example nhibernate, we're on par or sometimes faster than nhibernate in queries. So I can't give you cold hard benchmark data.

The following is the latest news I know about this subject.

Right, I was hoping there might have been some movement since then.

Support for Sybase has been halted for now. Sybase didn't return my emails nor are they providing a testdb installation (only for linux but we don't have a linux box here which we can reliably use for testing) which we could use for compiling our code against. So I think that's a showstopper for you.

Thanks Otis

Support for Sybase has been halted for now. Sybase didn't return my emails nor are they providing a testdb installation (only for linux but we don't have a linux box here which we can reliably use for testing) which we could use for compiling our code against. So I think that's a showstopper for you.

Hmm the slack@sses. It probably won't make a difference but we are a premium Sybase member so I'll mail them mentioning your product.

That would be great! Sybase is very similar to sqlserver, so supporting it won't be that hard.