Integrating UnitOfWork and XPObjectSpace descendants into an XAF app

We've made some code changes for v17.2.6+ as well as created two articles for advanced XAF developers who may need the subject for some low-level tuning:

How to customize the UnitOfWork behavior in XPO-based XAF applications

How to customize the Object Space behavior in XPO-based XAF applications

Sub-classing is itself easy.  The most interesting part comes for the two popular security configurations: the Integrated  mode and the Middle-Tier Application Server. Thankfully, this is rarely required for complex or specific scenarios only.  Here are several customer tickets for your reference:

    How to map a property to a calculated database column (implement a read-only persistent property)
    xpo and sql server identity fields
    Using inherited UnitOfWork object
    XAF: Create CreateCustomObjectSpaceProvider with parameters from login window
    SecurityStrategyComplex: How to modify objects/properties in code when the user does not have the permission?

To learn more about low-level options to control how your application saves data and where, check out the How to customize the underlying database provider options and data access behavior in XAF.

Your feedback is needed!
Finally, I am just curious: if you search your entire solution in Visual Studio (Control+Shift+F) for any of the ": UnitOfWork", ": XPObjectSpace", ": XPObjectSpaceProvider" strings or their VB.NET equivalents (e.g., Inherits UnitOfWork), how many occurrences  would you have and for what? Please let me know in the comments!

SQL Server-related methods of ModuleUpdater and pooled database connections

Before the end of this year, I wanted to inform you of some "home work" done by us to improve your XAF development experience with the ModuleUpdater API:

ModuleUpdater - CreateCommand and other SQL Server-related methods may throw NullReferenceException with pooled database connections

Welcome the DataStoreCreated event in the ConnectionDataStoreProvider and ConnectionStringDataStoreProvider classes

This is rather a minor improvement, but I bet it will save code lines for some advanced XAFers who touch the internals of the XPO data layer created by XAF for various low-level database-specific customization like setting connection timeouts, changing default schemas, enabling and customizing caching, service end-points, etc. Check out this updated article for some example code showing the new approach in action.

The DataStoreCreated  event is available in XAF v17.2+. Its event arguments (DataStoreCreatedEventArgs) expose the DataStore and Destination parameters that provide access to the current data store and its type (SchemaChecking,  Updating or Working).

Frankly speaking, this is quite low-level and rarely needed stuff, so we have not yet have it covered in the online docs, only in KBs. So, please refer to my 

How to customize the underlying database provider options and data access behavior in XAF article to learn more about it. Should you have any questions or additional usability suggestions, please let me know.

XAF app performance: Reducing the number of simultaneous database connections

Multiple simultaneously opened connections consume your database server memory and thus, have negative impact on your application performance. To diagnose this situation, you can use the following SQL script:

SELECT 
    DB_NAME(dbid) as DBName, 
    COUNT(dbid) as NumberOfConnections,
    loginame as LoginName
FROM
    sys.sysprocesses
WHERE 
    dbid > 0
GROUP BY 
    dbid, loginame

Thankfully, there is a couple of tricks to optimize your existing apps in production (they are already applied out of the box in new projects).