asked on
Shared Functions in Public Class
I have a User BLL class that contains shared functions for retrieval and updates of user records. I am declaring the functions as SHARED so I don't need to create a new instance of the UsersBLL everytime I need to use the functions. To further reduce the code size, I've created a read only property DetailsAdapter which only returns a new instance of UserDetailsTableAdapter each time its called. I just want to know if what I'm doing is thread safe? I'm just worried that I'm piling up new instances of DetailsAdapter in memory everytime I call a function. Will the DetailsAdapter object that I'm calling in every function gets destroyed after the function ends? Can somebody tell me the most efficient way to do this? Thanks.
Imports UserData
Imports UserDataTableAdapters
Public Class UsersBLL
Protected Shared ReadOnly Property DetailsAdapter() As UserDetailsTableAdapter
Get
Return New UserDetailsTableAdapter
End Get
End Property
Public Shared Function GetDetails(ByVal EmailAddress As String) As DataTable
Return DetailsAdapter.GetData(EmailAddress)
End Function
'etc. I have other Shared functions here that uses DetailsAdapter similarly
End Class
ASP.NET
Last Comment
Bob Learned
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
No, I mean that I wouldn't define any "data" elements in a "business" layer. A data adapter is a perfect example of a "data" element.
The second version is a good example of the singleton pattern, and it is the way that I prefer. You need an instance of a data adapter to fill a DataSet/DataTable, but you also need the same adapter to update the database from those in-memory objects.
The second version is a good example of the singleton pattern, and it is the way that I prefer. You need an instance of a data adapter to fill a DataSet/DataTable, but you also need the same adapter to update the database from those in-memory objects.
ASKER
@TheLearnedOne
Thanks for your answers. What I really want to know is if the the second version is thread safe. Will it be ok and will it not create a bottleneck if several users are accessing the function concurrently? I'm concerned that only a single instance of the DetailsAdapter will be available to all the users and their requests will be processed in queue / one at a time? I would greatly appreciate your answer on this.
Thanks in advance.
Meds
Thanks for your answers. What I really want to know is if the the second version is thread safe. Will it be ok and will it not create a bottleneck if several users are accessing the function concurrently? I'm concerned that only a single instance of the DetailsAdapter will be available to all the users and their requests will be processed in queue / one at a time? I would greatly appreciate your answer on this.
Thanks in advance.
Meds
Hmmm...DataTable, tableadapter, update method...it is my understanding that those are not inherently thread-safe. You would need some locking mechanism to create critical sections.
I'm not actually exposing the data adapter as it is Protected Shared right? It is only accessable by the functions inside the UsersBLL. The data adapters acts as my data access layer. I use them in my business layer (in this case UsersBLL) to get typed DataTables from my database and process them into business objects.
I just like to know if the new instance of the data adapters that I'm using in the functions gets destroyed after execution. I'm not sure which one is the better code below.
Open in new window