Re: Multiple concurrent isolated transactions on ADO Dataset

You don't need to keep the connection open

Why don't you use optimistic or pesimistic offline locking? (the optmisitc
one is more or less included in the dataadapter)

"Mark Roberts" <Mark_Roberts@xxxxxxxxxxxx> schrieb im Newsbeitrag
news:u%23B7CWvWFHA.3760@xxxxxxxxxxxxxxxxxxxxxxx
> Hi
>
> No, it's not really possible to operate directly on the database
> unfortunately - the changes that the user can make will be over a long
> time (i.e. could be 1-2 hours, maybe more)
>
> I don't really want to attempt to keep a database transaction open for
> that long :)
>
> Regards,
>
> Mark.
>
>
>
> "Rogas69" <rogas69@xxxxxxxxxxxxxxxx> wrote in message
> news:OpQNrSvWFHA.1796@xxxxxxxxxxxxxxxxxxxxxxx
>> What database do you use? You describe scenario that is easily handled by
>> practically any database. You said that amount of data is huge - creating
>> per-user copies will kill your server - think about memory allocation and
>> copying. Is it not possible to operate directly on database?
>>
>> Peter
>>
>> "Mark Roberts" <Mark_Roberts@xxxxxxxxxxxx> wrote in message
>> news:exDNqHvWFHA.612@xxxxxxxxxxxxxxxxxxxxxxx
>>> Hi,
>>>
>>> I have been thinking about a problem for some time, and i'd like to
>>> throw it open to the newsgroups in case someone has come across a
>>> similar situation.
>>>
>>> I have a C# .Net 2.0 web application with a very large server-side
>>> dataset (i.e. can only be 1 in memory).
>>>
>>> I have multiple users that wish to make changes to the dataset, and each
>>> user's should be batched up and only visible to themselves until they're
>>> committed, at which point they become part of the main dataset.
>>>
>>> I am thinking of have one dataset per user as well as the main dataset,
>>> and recording changes into the user-based dataset.
>>>
>>> This is ok, but it adds a lot of complexity when querying the data,
>>> since queries are essentially across two datasets.
>>>
>>> Ideally, i'd like to have multiple transaction layers on the main
>>> dataset, one for each user that isolates their changes, but permits
>>> dataset searching to work in the context of their transaction until it's
>>> committed or rolled back.
>>>
>>>
>>> Many thanks!
>>> Mark.
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: Help - Timing Logic
    ... server application, both of which ran on the same box. ... the client applications and 'lodging' them in the database. ... Another part of the server application was dedicated to retrieving messages ... commit transaction ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help - Timing Logic
    ... put a trigger on the database table. ... Transaction and Database Locking - look at isolation levels / settings ... Maybe implement a message broker ... ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help - Timing Logic
    ... build a trigger on the database .. ... Transaction and Database Locking - look at isolation levels / settings ... If you need to implement a locking mechanism / or / logging mechanism / or / a checking mechanism to avoid duplicate messages caused by multi-threading ... ... message broker gets all the necessary messages or message id's from the database to be sent ... ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help - Timing Logic
    ... put a trigger on the database table. ... Transaction and Database Locking - look at isolation levels / settings ... Maybe implement a message broker ... ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help - Timing Logic
    ... If you need to implement a locking mechanism / or / logging mechanism / or / a checking mechanism to avoid duplicate messages caused by multi-threading ... ... Is it the READ from the database ... ... Perhaps a stored proc may be faster to execute and return the values as opposed to building the transaction in the code. ... implement as above locking only the records you retrieve / update - need to watch out here for table locking ... ...
    (microsoft.public.dotnet.languages.vb)