On Mon, March 7, 2005 3:55 pm, Dakota Jack said: > The point is unavoidable, however, that whatever is persisted is > persisted on a file system somewhere.
No argument. But, when you do an an update to a database, there is a layer of abstraction (at least!) between your code and the file system, namely the RDBMS itself. In other words, it's almost like a remote procedural call conceptually... Maybe the JDBC driver uses RMI, or direct sockets, or whatever, but it tells the database to do the update, and it writes to the file system. It's not like your app server (more than likely) has access to the database servers' file system. So, while I don't disagree with you at all on this point, I don't see where it really matters. > The only difference between > modern databases and the old ones is that they have multiple files > which are related through some cool logic. Writing to a database is > writing to a file system, right? Absolutely. But then again, maybe not :) Maybe the database is an in-memory database only. Maybe it's writing directly to tape. Heck, maybe it's punching out punch cards in real-time! To the client that tells the database to do an update, they don't know or care. > I think what you are saying is that > you don't write to the manifold machines in the cluster but have some > other way of handling it. Not sure frankly what the term "manifold" means in this context. > Anyway, you don't need to know how the session is replicated, > accessed, etc. for this issue. You know that the session holds the > monitor and that is enough. Ok, I didn't understand that part... So, when the upload is initiated, you instantiate one of your monitor objects, do whatever setup it requires, and dump it in session? That is interesting... In a clustered environment like I deal with, that monitor would now be replicated across the cluster. So, when it went to check the status of the file, how does it now which server the file upload was originally going to? Maybe there is a way to identify a machine in a cluster (although I think someone else here tried to do it and couldn't find a way, but assuming you could...) and that way you could somehow request the status of the file. But, how? I mean, ok... Upload request goes to server A. Monitor is created and put in session. Let's assume we can tell that monitor what server the file is being uploaded to. Now, a request comes in a second later requesting the status of the file being uploaded, but that request goes to server B. Ok, we can get the SAME monitor instance from session, no problem there. But, now its executing within the context of server B, which means a DIFFERENT file system than where the file is being uploaded to. So, how can it get the status? Sure, if its being uploaded to a database you can probably query the database for the information you need, that's fine, but the only way to go directly to the file system (that I can see) is if you have a shared drive common to all the servers in the cluster. And as I mentioned earlier, thats not something that my admins allow (and if they are to be believed, IBM themselves tell you not to do it as well). > If you want, you can have a demon > notified that should monitors are finished and to have them nuked from > the session. The monitor is pretty light, so this is probably > overkill. That might work to maintain the monitors in session, which certainly would be valuable functionality. But I'm still stuck on the file system uploading "problems" :) Frank > <SNIP> > On Mon, 7 Mar 2005 15:46:48 -0500 (EST), Frank W. Zammetti > <[EMAIL PROTECTED]> wrote: >> I can say for sure that within our environment here, which is Websphere >> 5.0.1 on Linux, a cluster of about 20 machines (and a number of >> clusters, >> but the clusters themselves are independant so it's not relevant here), >> each request that comes in can be serviced by any of the 20 machines in >> the cluster. Regardless of which one a request is serviced by, the >> session is available. Is it writing to a common database? Or maybe has >> some RMI process working between them to do the session replication? I >> don't know that answer, although something like the second seems more >> likely to me, for the very performance reasons you rightly point our >> Leon. >> :) > <SNP> > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
