@Anonymous wrote:
@Revelate wrote:Oh boy, well not to get too technically uber geeky, distributed and remote applications are still bound by the speed of light.
Guess I failed on that one.
Same lender: I would suspect lenders have anti-duplicate application code for a whole lot of good reasons (including legal ones); this may prevent in some instances either two inquiries being lodged, or possibly has some have reported an inquiry being dropped later (note, could be a reporting issue or split file too on this second one).
Different lenders: On the assumption the same bureau is pulled, typically the report will be serially accessed; however, there are some distributed applications using database replication technologies vis a vis Oracle Golden Gate, where in theory they could have the application hosted in multipe datacenters in an Active / Active configuration, and then simply replicate transactions back and forth, and that's not necessarily instanteous nor necessarily serial... it has some interesting application design issues I suspect that I'm wholly unfamiliar with, but it's possible there may be some latency in multiple database requests and they may not be processed in such the same way that the inquiry would be immediately seen everywhere else in the infrastructure.
So it's theoretically possible, but I've never seen CRA data architecture, and assuredly smarter minds than mine have been detailed to figure out ways to prevent this sort of thing from happening; in general, I suspect it's pretty hard to accomplish and really you're getting lucky if it works in your favor. More trouble than it's worth I think, inquiries aren't that big of a deal in the model.
Yes, but distruted database systems take concurrency into account. This is necessary, of course, to preserve data integrity by preventing database updates performed by one user from intefering with the retrievals and updates performed by another. This is crucial for many applications, including but not limited to financial transactions, inventory control, airline/hotel reservation systems, etc. I don't know what platforms the CRAs run under, nor their database architectures, but I would have to believe that they would take this issue into account.
ETA: My original post was simplified for the non-geek. But to be a bit more specific, if done properly, a credit pull should be handled as an atomic transaction, whereby the entire request -- pulling the info, sending it back to the requestor, recording the inq -- should all be handled as a complete transaction before allowing another request to proceed; or erroring out and not performing any of the request. Once again, this is necessary in this type of a system to preserve integrity. This being the case, I would tend to discount the idea of the two browser trick.
Tin...this hurt my brain and I am a pilot!! 
I am with youngandcreditworthy, i just wanna try it anyway. lol
@ Pilotdude
I read it 2x and my head hurts from thinking about doing this now!
I read it 2x and my head hurts from thinking about doing this now!
@Revelate wrote:
<snip>
Different lenders: On the assumption the same bureau is pulled, typically the report will be serially accessed; however, there are some distributed applications using database replication technologies vis a vis Oracle Golden Gate, where in theory they could have the application hosted in multipe datacenters in an Active / Active configuration, and then simply replicate transactions back and forth, and that's not necessarily instanteous nor necessarily serial... it has some interesting application design issues I suspect that I'm wholly unfamiliar with, but it's possible there may be some latency in multiple database requests and they may not be processed in such the same way that the inquiry would be immediately seen everywhere else in the infrastructure.
<snip>
You piqued my interest regarding Oracle Golden Gate, so I decided to take a look at some of the specs. Yes, it does replicate transactions across multiple servers and/or data centers, which would necessarily involve a certain amount of latency. The following link describes the modules responsible for maintaining data integrity. Since the capture module looks for transactional activity, and updates the replicated databases as these soon as these activites are detected, the most recent update would be used for any further queries. And since these are handled as transactions, which are atomic in nature ("The Capture module only moves committed transactions — filtering out intermediate activities and rolled-back operations — which not only reduces infrastructure load but also eliminates potential data inconsistencies"), I am hard pressed to see how a query would return a result that does not contain the latest, updated data -- including the inquiry.
http://www.oracle.com/us/products/middleware/data-integration/goldengate11g-ds-168062.pdf
Of course we still don't know what database platform the DBAs are using, although I would tend to believe that it may well be something enterprise level, such as Oracle. But it still seems to me that they have indeed addressed the concurrency issues.
As for the rest of the folks in this thread who want to give it a shot -- by all means, and feel free to report back. I always like to hear the results of an experiement. 
I'm still stuck at 'Oracle and Golden Gate'!