Hi Mohammad -
Well... the config store interface is transactional, but you normally would
not want a user to read under a transaction, keep the transaction open
while they changed the values in the GUI, and then wrote them back - this
would be too slow and you don't want user interaction in the middle of
transactions.
So that is why we have the design this way - you read the entire set of
config into, and you write the entire set back - this means that *your*
info is always consistent at least. But it doesn't prevent you from
overwriting someone else's info. Last one wins.
Hope that helps.
--------------------
Thread-Topic: Using SSO as a ConfigStore
thread-index: AccR5+EccDQJ+45oQEuL7wOVTh65dA==
X-WBNR-Posting-Host: 195.226.232.5
From: =?Utf-8?B?TW9oYW1tYWRTSA==?= <***@discussions.microsoft.com>
References: <55089D77-B739-4DB4-941B-***@microsoft.com>
<***@TK2MSFTNGXA01.phx.gbl>
Subject: RE: Using SSO as a ConfigStore
Date: Sun, 26 Nov 2006 21:50:01 -0800
Lines: 89
Message-ID: <C08BCDC5-3DB1-4575-A8C1-***@microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Newsgroups: microsoft.public.biztalk.framework
NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
Path: TK2MSFTNGHUB02.phx.gbl!TK2MSFTNGXA01.phx.gbl
Xref: TK2MSFTNGHUB02.phx.gbl microsoft.public.biztalk.framework:1
X-Tomcat-NG: microsoft.public.biztalk.framework
Thanks for your reply,
Post by Steve Jamieson [MSFT]then in a
multi-user environment you may think you set your value to what was
displayed on your screen, but some other user may have changed it in the
meantime. So by having things work this way we can guarantee that your set
of properties is consistent, and is what you expect.
This means that the other user will have his value changes lost! Is there a
way to avoid dirty reads/writes?
Thanks
Post by Steve Jamieson [MSFT]Hi Mohammad -
Yes, that is correct, you must set every value in the property bag
otherwise it is considered that the property is missing and hence it is set
to empty. If you don't know the value or want to leave it alone you need to
set it to VT_NULL.
Why did we do it that way? Well, the intent of this interface is to get a
set of properties that are updated as a compete set by some UI tool. If we
allowed setting of only some properties and not others, then in a
multi-user environment you may think you set your value to what was
displayed on your screen, but some other user may have changed it in the
meantime. So by having things work this way we can guarantee that your set
of properties is consistent, and is what you expect.
Hope that helps.
Steve J.
--------------------
Thread-Topic: Using SSO as a ConfigStore
thread-index: AccL1yJATVySuOWbT1iCU+6S+9G+3w==
X-WBNR-Posting-Host: 195.39.170.102
Subject: Using SSO as a ConfigStore
Date: Sun, 19 Nov 2006 04:35:02 -0800
Lines: 21
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Newsgroups: microsoft.public.biztalk.framework
Path: TK2MSFTNGXA01.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.biztalk.framework:3741
NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
X-Tomcat-NG: microsoft.public.biztalk.framework
Hi,
I am using SSO as a ConfigStore for my applications, and everything seems to
be working ok. However, when updating a property value, when I only supply
the property that I wish to update in the PropertyBag, other properties'
values get nullified.
"If the configuration info does already exist, then if a property is set to
VT_NULL, it retains its existing value. If it is set to any other new value
(including VT_EMPTY) it is updated. If it is missing from the property bag
it
is set to VT_EMPTY"
What I understood from this is that I either need to provide the value of
existing properties, or set their values to DBNull.Value for them to keep
their original value (I've tired it and it works), so it looks to me like
this is the only way to update a vaue, is to set everything else as well, Is
this true? If it is, then Why?!
Thanks,
Mohammad
This posting is provided "AS IS" with no warranties, and confers no rights.
EBusiness Server Team
This posting is provided "AS IS" with no warranties, and confers no rights.
EBusiness Server Team