|
From: Viktor M. <MIH...@de...> - 2001-11-20 11:18:06
|
Hi Marcin,
the behaviour in the case described is just right, if the filesystem has
been unmounted (e.g., bypassing the CIMOM), it is effectively no longer
there and hence should not be returned by getInstance. A cache would have
to account for this situation as well for coherency reasons, which is at
least difficult, if not impossible. Don't want to go into the evil details,
but imagine multiple clients that are accessing the CIMOM in parallel AND
somebody modifying the real resources....
Mit freundlichen Grüßen / Kind Regards
Viktor Mihajlovski
Linux Technology Center
IBM Laboratory Böblingen, Germany
Phone +49-7031-16-2560
E-Mail mih...@de...
Marcin Gozdalik
<go...@go...> To: Heidi Neumann/Germany/IBM@IBMDE
Sent by: cc: sbl...@ww...
sblim-devel-admin@www-1 Subject: Re: [Sblim-devel] Java VM bug?
26.ibm.com
11/20/01 12:26 AM
Please respond to
Marcin Gozdalik
On Mon 19. November 2001 15:44, you wrote:
> In terms of data consistency and performance a provider cache
> would not be the best solution for FSVOL . That solution
> would force overhead in memory management and you lose
> performance . Its not necessary for this kind of provider .
> Maybe in another content such a solution would be the best
> way to go but here I recommend to use the direct access .
Well, some kind cache is inevitable IMHO. Simply enumInstancesNames returns
names of currently mounted filesystems but before CIMOM issues a
getInstance
somebody could remount some of the filesystems, so getInstance would have
to
return an error which isn't an expected behaviour. Or was this whole
situation thought of before and it's covered somewhere in the CIMOM specs I
haven't got the opportunity to read?
--
Marcin Gozdalik <go...@go...>
_______________________________________________
Sblim-devel mailing list
Sbl...@ww...
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/sblim-devel
|