|
Aqui para los que dicen que SQLite3 no es multiconcurrente, acabo de hacer otra prueba, aun mas extensa.
1. Misma base de datos anterior que contiene dos tablas: Pais y Pais1.
La tabla Pais ya existe, con la data original de todos los paises (ya explicado antes) y es unica que se usa en esta prueba. La tabla Pais ya contenia 239 renglones, uno para cada pais.
2. Una aplicacion que manda los comandos que se le carguen, se abre dos veces, en dos instancias: App1 y App2
3. Se le carga a ambas el MISMO set de commandos SQL. Este set carga los 239 paises del planeta, con sus respectivas estadisticas, ya descritas.
4. Esta es una tira tipica de las 239 tiras del set:
INSERT INTO "country" VALUES('GUM','Guam','Oceania','Micronesia',549,NULL,168000,77.8,1197,1136,'Guam','US Territory','George W. Bush',921,'GU');
I
5. Amartillo las dos aplicaciones de tal manera que los botones de App1 y App2 de mando estan a un centimetro de separadas y el tiempo en presionar el boton de mando en App1 y App2 es minimo.
6. Como ahora no se crean tablas, y la tabla permite cargar duplicaciones, nada me impidio que me diera vuelo en presionar App1 y App2 alternandolos MUCHAS VECES y SIN LIMITE ALGUNO que el de mi rapidez y en unos cuantos ciclos la tabla Pais tiene ya 30,000 paises apx. Ni una sola de las veces rechino ni salio mensaje que me impida repetir esto hasta el cansancio.
No conte los cliks que di, pero dividiendo me resultan 125 transacciones A LA MISMA TABLA Pais que SQLite3 recibio correctamente, sin chistar.
Como ven, a SQLite no le importa a cual tabla le envien el grabado, siempre y cuando la data que se le mande sea correcta.
P.S. Me tarda mas escribir este mensaje que hacer las pruebas. SQLite3 todavia me esta esperando para que les siga picando el boton a App1 y App2, pues todavia las tengo preparadas y les puedo seguir picando los botones. Mas la verdad es que no le veo el caso. Para mi esto es concurrente y multiusuario. Que haya mas capacidad que esto, no lo niego.
|