Hi,
When I create a new DataContext, I understand that LinqConnect create his own connection to the database.
If a create a lot of DataContexts, this will create a lot of connections.
Is it possible to share the same connection with all the DataContexts?
With Mindscape LightSpeed, they use a ConnectionStrategy. This is a property of the DataContext that is assign immediatly when you create a new DataContext. After that, when LinqConnect try to create a new connection, they use instead the connection injected previously and now we have the control to keep a single connection for the entire live of the application.
With WinForms application, this could be great.
Thank you.
Share connection
Hey
At LinQConnect, you can choose the connection string by creating the DataContext like
When you dispose the myDataContext, then the "Connection" is also dropped.
This will be the only way, how it should work, becuase when you are able to change the Connection String during the lifetime of the DataContext, then you can't be sure any more, that the model works with the underlaying classes. For example, you can't know anymore, if a value has been changed or even it is maybe a new value.
And as written in the other posts to you, a project-lifetime DataContext is not the best way!
I have made the experience, that the Refresh Method always would use more time, then creating and quering a new DataContext.
At LinQConnect, you can choose the connection string by creating the DataContext like
Code: Select all
Dim myDataContext = New Project.Model.DataContext(ConnectionString)
This will be the only way, how it should work, becuase when you are able to change the Connection String during the lifetime of the DataContext, then you can't be sure any more, that the model works with the underlaying classes. For example, you can't know anymore, if a value has been changed or even it is maybe a new value.
And as written in the other posts to you, a project-lifetime DataContext is not the best way!
I have made the experience, that the Refresh Method always would use more time, then creating and quering a new DataContext.
-
StanislavK
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
Please specify whether you mean physical connections or DbConnection objects.
DataContext opens the connection for querying data or submitting changes only; after these operations are performed, the connection is closed and returned to the pool (provided that you didn't turn off pooling). At this point, the physical connection remains opened and can be reused whenever a DbConnection object (which can belong to other DataContext) with similar connection string opens again. In this way, multiple DataContexts share the same physical connection (as long as they don't address the database simultaneously).
DataContext opens the connection for querying data or submitting changes only; after these operations are performed, the connection is closed and returned to the pool (provided that you didn't turn off pooling). At this point, the physical connection remains opened and can be reused whenever a DbConnection object (which can belong to other DataContext) with similar connection string opens again. In this way, multiple DataContexts share the same physical connection (as long as they don't address the database simultaneously).
Mystcreater,
From your comments, it is apparent that you have weak knowledge of the way a data access layer should work. If you find useful to open a lot of (physical?) connections and DataContexts to a database and you find this thing great even for a WinForms application, i think you are not yet in a position to evaluate or even appreciate an ORM solution. Many vendors have their reason(sales!) to present their products as "plug n play" solutions that fit into any need without proper basic knowledge. Take my word for it, this is hardly the case, especially for an ORM solution! Proper choice of an ORM solution demands professional knowledge of software architecture layers, to which, one usually gets, when he has enough experience to actually start to build such a solution!
My advice for you is to start design things a little bit, understand about data access and business layers and then try to incorporate an ORM solution to fit your needs. If you have small projects that span a few thousand lines of code, an ORM solution that you are not really comfortable with, will probably increase project completion time more that you can handle.
That said, i use LinqConnect in a CRM Application Server solution spanning 23 projects, 10 WCF Services that get loaded in different application domains in the same process, serving hundreds of concurrent DB requests from Win, Web, Silverlight and Mobile Clients through multiple web service threads. And yes, everything works rather smooth. But this is more because i really know where an ORM solution fits and less because LinqConnect offers everything out of the box! For example, in such an implementation where hundreds of concurrent Database requests are needed, if i kept a large number of open connections without using the facilities of connection pooling and creating and disposing datacontexts when needed, i would reach connection exhaustion really fast and the exceptions raised would be continuous! And LinqConnect or any other ORM solution would have nothing to do with it!
I really hope you get my point...
From your comments, it is apparent that you have weak knowledge of the way a data access layer should work. If you find useful to open a lot of (physical?) connections and DataContexts to a database and you find this thing great even for a WinForms application, i think you are not yet in a position to evaluate or even appreciate an ORM solution. Many vendors have their reason(sales!) to present their products as "plug n play" solutions that fit into any need without proper basic knowledge. Take my word for it, this is hardly the case, especially for an ORM solution! Proper choice of an ORM solution demands professional knowledge of software architecture layers, to which, one usually gets, when he has enough experience to actually start to build such a solution!
My advice for you is to start design things a little bit, understand about data access and business layers and then try to incorporate an ORM solution to fit your needs. If you have small projects that span a few thousand lines of code, an ORM solution that you are not really comfortable with, will probably increase project completion time more that you can handle.
That said, i use LinqConnect in a CRM Application Server solution spanning 23 projects, 10 WCF Services that get loaded in different application domains in the same process, serving hundreds of concurrent DB requests from Win, Web, Silverlight and Mobile Clients through multiple web service threads. And yes, everything works rather smooth. But this is more because i really know where an ORM solution fits and less because LinqConnect offers everything out of the box! For example, in such an implementation where hundreds of concurrent Database requests are needed, if i kept a large number of open connections without using the facilities of connection pooling and creating and disposing datacontexts when needed, i would reach connection exhaustion really fast and the exceptions raised would be continuous! And LinqConnect or any other ORM solution would have nothing to do with it!
I really hope you get my point...