This message is targeted to the people at llblgen but others out there please chip in if you have comments!

I am shopping around for an O/R Mapping tool to use for a new project and for the indefinite future (at least until MS release ObjectSpaces and probably beyond that if I get accustomed to using the tool!).

I spoke to a sales person at Alachisoft (makers of TierDeveloper) who claimed that LLBLGen's code would not perform well (fast) if there were more than 20 or so tables. I suspect that this is just FUD (Fear, Uncertainty and Doubt) being raised by him but wanted to ask LLBLGen and this forum.

My project has a database of about 30 tables and will have about 1000 users (estimated to be an average of 300 connected at any given time). My estimated transaction rate will be 20 transactions per second (for updates, deletes, appends) and 100 per second for reads.

Interfacing to the database will be via web services as clients are all remote and on public networks.

This doesn't seem challenging at all to me and I hadn't even considered that LLBLGen wouldn't be able to handle it until the comment from Alachisoft.

Any comments on the suitability of LLBLGen for my project?

I've tried several O/R Mapping tools (including TierDeveloper) before purchasing LLBLGen, I think LLBLGen is easy to learn and use, and it is flexible to add custom coding to generated classes.

My porject has over 500 tables on SQL Server and running .Net remoting, I don't have any performance issues so far, it's fast and stable. And support team from LLBLGen is great, they are helpful and response quickly, even duing holidays.

However, I don't sure which one is faster in performance, I think you better download a trial version of both LLBLGen and TierDeveloper, and create a sample application perform some testings.

Emmanuel wrote:

I spoke to a sales person at Alachisoft (makers of TierDeveloper) who claimed that LLBLGen's code would not perform well (fast) if there were more than 20 or so tables. I suspect that this is just FUD (Fear, Uncertainty and Doubt) being raised by him but wanted to ask LLBLGen and this forum.

Who said that, do you have an email address for me so I can ask them myself why they spread that kind of crap? LLBLGen Pro is very fast, also in large applications (it's used with systems with over 2500+ tables without problems) and doesn't suffer from scaling problems because its meta data is generated in code, not kept in structures internally.

These alachi people start to get on my nerves...

Emmanuel wrote:

My project has a database of about 30 tables and will have about 1000 users (estimated to be an average of 300 connected at any given time). My estimated transaction rate will be 20 transactions per second (for updates, deletes, appends) and 100 per second for reads.

Interfacing to the database will be via web services as clients are all remote and on public networks.

This doesn't seem challenging at all to me and I hadn't even considered that LLBLGen wouldn't be able to handle it until the comment from Alachisoft. Any comments on the suitability of LLBLGen for my project?

It won't be a problem. The only thing you can run into is problems which are related to webservices like no support for polymorphic return values: [Webmethod] public CustomerEntity GetCustomer(...)

returns always a CustomerEntity type, even if you return an instance of a subtype of customer, which leads to problems on the client. This is a problem with webservices. Also build webservices with messaging, not by passing large blocks of data back and forth. If you want to pass large blocks of data, better use remoting, as that's more compact.

For the past few years, since LLBLGen Pro was release, I have used and deployed LLBLGen Pro based solutions for major clients in the UK. These application have been a combination of Web and Windows application and have truly been Enterprise applications i.e. minimum 50 tables, normalised (Note: this does not help performance, but has maintenance advantages).

Trust me, these are HIGHLY demanding applications, and guess what, performance has not been an issue to date.

My feeling is that you should treat the advise from this person from Alachisoft as highly suspect and publish his name so that we can all have a change to challenge it.

Please note, I provide support for LLBLGen Pro for one reason only: I truly believe it to be a product that will provide the performance (amonst other key thinks like reliebility, supportability, flexibility).

{Edit} References can be provided as well

I've been using LLBLGen for two years. The biggest project I've done with LLBL uses 400+ tables (so far and its growing). The issue I will raise here is not about performance as I have experienced first-hand how first-notch performer can an LLBL generated DAL perform. What I will raise here is the issue of maintenance. Take my word for it, the bigger the project gets in size the worse you start to loose control over maintaing your database changes to your code. LLBL solves this issue beautifully. I can go crazy changing all sorts of things in my DB and it takes me 5 minutes to generate the DAL and depoly it to the rest of the team. Promoting this true-tiered approach to devolopment made all our lives easier and our customers happier. If thats not enough, wait tell you try the support here, there's nothing like it in the whole industry... If and whenever Ms-ObjectSpace is realeased, I am all confident that LLBL is years ahead in maturity and usability. As Frans once said it, LLBLGen is the dream come true for DB access to a .NET devoloper... this is 100% correct NOW and still more goodies are coming up in V2.0

Otis wrote:

Emmanuel wrote:

I spoke to a sales person at Alachisoft (makers of TierDeveloper) who claimed that LLBLGen's code would not perform well (fast) if there were more than 20 or so tables. I suspect that this is just FUD (Fear, Uncertainty and Doubt) being raised by him but wanted to ask LLBLGen and this forum.

Who said that, do you have an email address for me so I can ask them myself why they spread that kind of crap? LLBLGen Pro is very fast, also in large applications (it's used with systems with over 2500+ tables without problems) and doesn't suffer from scaling problems because its meta data is generated in code, not kept in structures internally.

The salesperson was Andy Iqbal (andy@alachisoft.com). He's their inside sales manager. I asked him how TierDeveloper compared to LLBLGen and he told me that LLBLGen doesn't scale well like TierDeveloper and said that if my app had more than about 25 to 30 tables I'd be in trouble with LLBLGen. I wasn't stupid enough to take what he said at face value because 1) he's a salesperson, 2) who in the world would release an O/R Mapper product that could only support <25 tables well! By the way, Alachisoft seems to be actually Diyatech (www.diyatech.com) based on my research.

Otis wrote:

These alachi people start to get on my nerves...

For the last 4 years I was a marketing manager for a high-tech company in a very competitive field so I know what it is like to deal with competitors. Frustrating, but you can't argue that it doesn't give you motivation to fight back, eh!?

===

I downloaded a trial version and have begun reading the "Concept" section as you advise. And I must say that I am confused about the lack of locking in your tool. How does one handle the following?...

1. Lost updates - I gather one just manually does a compare on rowversion (timestamp) before committing changes. Usual optimistic concurency stuff, right?

2. Dirty reads (reading a record that is not yet committed and is ultimately rolled back)?

3. Phantoms (record is deleted during the course of another user's update to the record)?

I'm sure there is a way given the glowing feedback from others in this thread who have apps that are much bigger than mine!

As for remoting, thanks for the tip. To be honest I don't understand yet but I'll read up on it (I confess that this is my first web app - I last wrote apps in the 90's under win32).

Thanks!

I'll just share my own Alachisoft horror story.

They are notorius SPAMers. I mistakenly gave them my email address once, and no matter how many times I tried to unsubscribe they kept blasting emails at me.

Finally I had to blast one back, including to their ISP, partner companies, and every customer I could find, detailing the many times I'd tried to unsubscribe from them and repeating my request. That got their attention, and they promised they would remove me from their lists.

You'd think that would have happened. It didn't.

Some weeks later I started getting LinkedIn invitations from thier salespeople.

The nightmare never ends from Alachisoft. It's a company driven by salespeople who won't follow the rules, including, as described earlier in this thread, lying about competitors.

Beware Alachisoft.

LLBLGen Pro doesn't use database locks on table rows to prevent some sort of concurrency control;

That must be the line that confused you , it means that LLBLGen Pro doesn't force a concurrency control on you, yet it supports all modes. You will have to decide what level or mode you want to use.

The following was copied from LLBLGen Pro documentation

_Design your concurrency scheme before you start creating a LLBLGen Pro project. LLBLGen Pro supports all concurrency schemes thinkable using the IConcurrencyPredicateFactory interface you can implement to specify per-entity concurrency control. If you want to use timestamp columns for example, be sure you define these up front in the schema

How do I implement concurrency control? Concurrency control is something that can be implemented in various ways. Because there are numerous ways to implement concurrency control (abstract concurrency control using functionality locking, low level concurrency schemes with optimistic locking or pessimistic locking, all fields filters, timestamp filters etc.), the generated code offers you the tools to produce the concurrency scheme you want. To implement low level concurrency control like optimistic locking, predicates are used to limit the scope of a query executed. These predicates are added to the query being executed, for example an update query or a delete query, as a new clause to the WHERE clause of the query, using AND.

To produce these predicates automatically, it's wise to implement IConcurrencyPredicateFactory for the class(es) you want concurrency control for. See the sections about concurrency control (Selfservicing or Adapter) for more details about this._

For further reading please check the subject:Concurrency control in the LLBLGen Pro documentation under "Using the generated code - Adapter/SelfServicing - Using the entity classes"

Walaa wrote:

LLBLGen Pro doesn't force a concurrency control on you, yet it supports all modes.

Thanks. That's a relief. Maybe you want to change the text in the concept section. It gave me a scare despite the following paragraph that told me not to panic

I really really like the idea of polymorphic entities in your tool (I'm an old C++ guy). I don't quite understand how to implement it at the db level yet (my 1st serious db project) but I'm sure I'll figure it out as I keep reading.

Thanks for the answer.

To elaborate: LLBLGen Pro doesn't perform locking by itself, because it can severily hurt performance and requires connections to stay open for much longer than anticipated. It leaves the locking to the database system, and offers a concurrency implementation method which is flexible enough to implement concurrency in various ways. Pessimistic concurrency with locks is therefore hard to do, but at the same time, the scenario's in which pessimistic concurrency is really desired are rare.

Please read my article about concurrency here: http://weblogs.asp.net/fbouma/archive/2003/05/24/7499.aspx

Otis wrote:

Please read my article about concurrency here: http://weblogs.asp.net/fbouma/archive/2003/05/24/7499.aspx

I'm not convinced yet but I certainly agree with your philosophy of functional locking. My problem is that I have a couple of applications that access the database and I only control one of them so some form of locking must be pushed down to the DB as the final gatekeeper.

Otis wrote:

Pessimistic concurrency with locks is therefore hard to do...

My understanding is that I am responsible for writing the functional locking logic using the ConcurrencyPredicate framework provided but how do I ALSO cause DB level locks to be placed (to handle the other apps over which I have no control)?

What are other users doing?

Emmanuel wrote:

Otis wrote:

Please read my article about concurrency here: http://weblogs.asp.net/fbouma/archive/2003/05/24/7499.aspx

I'm not convinced yet but I certainly agree with your philosophy of functional locking. My problem is that I have a couple of applications that access the database and I only control one of them so some form of locking must be pushed down to the DB as the final gatekeeper.

Any exclusive lock set by a thread outside the db blocks all other threads who wants to read the row (for example if a filter is used over a field which doesn't have an index, then a tablescan occurs). At least on Sqlserver. So the main point is to keep the lock time as short as possible and you have to be sure the lock is lifted no matter what.

Do achieve that, you use a transaction. With a transaction, locks are set by the RDBMS and lifted when the transaction is committed or rolled back.

Otis wrote:

Pessimistic concurrency with locks is therefore hard to do...

My understanding is that I am responsible for writing the functional locking logic using the ConcurrencyPredicate framework provided but how do I ALSO cause DB level locks to be placed (to handle the other apps over which I have no control)?

The concurrencypredicate factory object is used to produce filters for concurrency at runtime, for example that an update only occurs if a timestamp field value is the same value as teh value in the entity in memory. (otherwise it is updated in the db, and the update should fail).

If you first lock, then present the values, the user starts editing, perhaps takes 5 minutes then you persist the changes, you locked a row or rows for 5 minutes. Over a live connection. That doesn't scale. With a transaction, the rdbms controls what's locked, so no worries (what you update during a transaction is locked for other threads).

Thanks Otis. I should have read the rest of the manual. If I had I would have seen the Transactions section. I don't have any more worries.

Emmanuel wrote:

Thanks Otis. I should have read the rest of the manual. If I had I would have seen the Transactions section. I don't have any more worries.

We've received your .lgp files btw. I'll have a look at them tomorrow. Thanks for reporting the issue. I'll keep you posted in the thread in bugs/issues.

One problem with LLBL and large DB projects (100+ tables). Due to ammount of classes and code generated (especially in SelfServicing) it is becomming more and more complicated to develop with those classes. Builds are getting longer, Intellisense is getting slow, such "great" tools as Intellij Resharper becomes unusable with so many methods in factories and so many properties and collections in entity classes. However I it is minor inconvienience and there is no performance degradation with larger DBs

large codebases indeed intend to become slow in the IDE. Compile times are much lower when you compile in the command line though (as it's generated code, that's not a problem) and reference the assemblies instead.

One class which should be omitted from large codebases is the predicatefactory (and also the sortclausefactory). As they're no longer needed (because you can use the much easier field op field/value approach using operator overloading in 1.0.2005.1), they can save a lot of space and compile time.

Personally, I'm a fan of the large codebase slowdown. It's convinced my boss to buy us all new powerhouse workstations

How do you omit predicatefactory and sortclausefactory?

JimFoye wrote:

How do you omit predicatefactory and sortclausefactory?

creating a custom generator config and remove the tasks which generate them, or delete them by hand/exclude them from the vs.net project.

On large projects, I typically will generate the code (DAL) and compile into a DLL. I then reference the dll. This speed's up the IDE quite a lot.

Yeah I'm starting to think about that.