style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Concurrencia

Hola a todos los colegas, me encuentro desarrollando un software para gestionar un negocio, el punto es que tengo que centralizar mi base en un lugar y puede haber muchos usuarios interactuando con ella y no quiero que se me colapseeee!, ya que no utilizo un servidor de aplicaciones para gestionar los pools, se que tengo que utilizar hilos y hacer todos los metodos de acceso sincronizados, pero alguien tiene alguna idea. mi aplicacion esta hecha en Swing , MySql, y utilizo Hibernate como motor de persistencia. espero Noticias ...Saludos. :)

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

Concurrencia

Tu si que andas perdido en el espacio. ¿Por qué utilizar dos herramientas de persistencia de filosofia tan distinta?.. o MySQL o Hibernate.. no recomiendo ambos a la vez para una misma aplicacion.

Suponiendo que te decidas por MySQL, pues depende de qué "Storage Engine" configures:

http://dev.mysql.com/doc/refman/5.0/en/storage-engines.html.

Al menos tiene dos muy ampliamente utilizados: el MyISAM y el InnoDB.

El primero (MyISAM) es sumamente rapido para lecturas, recomendado para sitios web densamente visitados. Pero su desventaja es que no garantiza ACID.

Si lo que deseas es un engine que garantice ACID entonces configura para usar InnoDB, asi te quitas de problemas de concurrencia al utilizar MySQL.

Saludos desde Aguascalientes.

Imagen de ezamudio

Hablando de perdidos... creo

Hablando de perdidos... creo que te confundiste. MySQL es un servidor de base de datos (bastante limitado en mi humilde opinion, sobre todo por lo que dices de ACID y aun cuando se use InnoDB parece que hay problemas de validacion de datos, integridad, etc) y Hibernate es un framework de persistencia que es independiente de la base de datos que utilices... puedes utilizar Hibernate con MySQL, o PostgreSQL, Oracle, SQLServer, etc etc. Ocars no menciona dos frameworks de persistencia, solamente uno: Hibernate, y una base de datos: MySQL.

Lo que no entendi es cómo está el diseño de "ocars" que menciona hilos, pools, metodos de acceso sincronizados, una aplicacion centralizada... y Swing? Swing es para interfaz gráfica en aplicaciones de escritorio, no me imagino cómo es que está centralizado algo asi, tal vez está haciéndola al viejo estilo "cliente-servidor" donde el servidor era nada mas la base de datos y cada cliente es una aplicación de escritorio que se conecta directo al servidor de base de datos... cosa que no es nada escalable.

Given the choice of dancing pigs and security, users will choose dancing pigs, every single time.
Steve Riley

Imagen de iberck

Hablando de perdidos

De acuerdo con ezamudio, MySQL e Hibernate son cosas muy distintas.

Hola ocars:
Según lo que entiendo tienes una aplicación de escritorio en distintos nodos
las cuales se conectan a una bd centralizada y necesitas manipular la concurrencia ...

Tu solución es poco escalable como comenta ezamudio ya que al mínimo cambio debes
replicarlo en todos los nodos donde tengas instalada la aplicación (a menos que manejes un sistema
para la actualización de tu app).

En primera instancia lo que necesitas es sincronizar son los eventos de tu aplicación
para evitar que se colapse en ciertos puntos (tal vez lanzar un thread cuando quieras
insertar algo hacia la base de datos para que tu aplicación no se quede en espera).

Para sincronizar el acceso a la base de datos lo puedes realizar por medio de
transacciones y manejar los niveles de isolación de la base de datos.

Espero te sirva
iberck

Imagen de ocars

Exactamente eso es lo que

Exactamente eso es lo que pretendo hacer, mi aplicacion es de escritorio, el programa pretende atender varios usuarios con diferentes tipos jerarquicos y con diferentes permisos, pero no quise utilizar un modulo web, para desarrollarlo, sino que me quise ir por swing para paracticar clases internas y lenguaje un poco mas basico, pero me encontre con el problema de concurrencia que un servidor de aplicaciones se te hace de forma facil, asi que como ya me obsecione, ahora quiero hacer el control de las transacciones yo mismo, pero me estoy dando cuenta que el mantenimiento va a ser muy dificil, pero les agradesco los tips, gracias ezamudio, iberck y nuestro vecino de aguascalientes.

ahi cuando lo termine les aviso y subo un demo para que lo vean, saludos

Imagen de beto.bateria

Saludo ocars: Te recomiendo

Saludo ocars:

Te recomiendo que te olvides de crear el servidor, si lo haces te vas a meter en problemas, tambien vuelve a pensar lo de hacerlo con swing, desgraciadamente ya es una tecnologia que la dejaron en el olvido. Aqui te menciono dos opciones, incluyendo swing, si es que insistes:

- Una aplicacion web utilizando algo conocido como tomcat, un framework MVC (hay muchas opciones), y alguna libreria para la interface de usuarion como GWT, icefaces u otra (tambien hay mucha variedad).

- La GUI seria con Swing y se comunicaria con el servidor a traves de webservices o xml, podrias utilizar tambien tomcat y un framework MVC.

DarkScripter a #EstanMaloProgramando

Imagen de ezamudio

no web services

Si tu backend y tu frontend están en Java, por qué mejor no usar algo como RMI? o en todo caso puedes usar Apache Thrift. Son maneras más sencillas de llegar a lo mismo, sin todo el overhead del XML.

O Protobuf.. :) Bueno en

O Protobuf.. :) Bueno en realidad solo lo digo porque me gustaría conocer a alguien que lo usara.

Imagen de ezamudio

Thrift > Protobuf

Una comparación (algo vieja) de Thrift y Protocol Buffers.

Pero cualquiera de las dos opciones le gana por mucho al maldito web service de XML sobre HTTP.

Estaría bien ver la

Estaría bien ver la diferencia 3 años después. El post fue de la fecha de liberarción y segun Ohloh el codigo de protobuf ha crecido casi 100% ( ademas que hay varios ports para lenguajes no oficialmente usados por Google como C# o incluso Go )

En fin yo no he usado ninguno de los dos ( ni pienso usarlo en el corto plazo ) así que si alguien escribe algo al respecto con gusto lo leeré.

:)

Imagen de ezamudio

una más nueva

Aquí una comparación más reciente. Protobuf le gana a Thrift en todo, al parecer.

Yo quería usar Thrift para un servicio que me pidieron publicar, total, era muy fácil, podía decirle a quienes quisieran consumir el servicio, que bajaran Thrift y darles el archivito de definición y que compilen el cliente para lo que quieran, o de plano compilárselos yo, pero NOOOOOOO, tuve que hacer el web service con XML sobre HTTP porque algunos clientes tienen como política de la empresa solamente consumir web services, no pueden usar otro protocolo. Qué clase de estupidez es esa? Quién fue el imbécil que mandó poner una política así? En fin.

Imagen de beto.bateria

Que tal: ezamudio, hay un

Que tal:

ezamudio, hay un contenedor o servidor que de "servicios" de RMI?
Creo que el fin es evitar el desarrollo de un servidor con sus problemas de concurrencia.

Imagen de ezamudio

cualquiera

Los problemas de concurrencia no te los vas a quitar de encima porque los tienes que contemplar en tu código, en tu base de datos, en tus transacciones, lógica de negocio, etc.

Cualquier contenedor te debe dejar publicar un EJB por RMI. Alguna vez lo hice, afortunadamente ya olvidé ese tormento, fue con EJB2, tal vez los 3 sean una maravilla, no pienso averiguarlo.

Con Spring es regalado publicar un servicio por RMI:

1. Creas una interfaz para tu objeto, si es que no la tienes ya, con los métodos que quieres publicar.
2. Te aseguras que las clases utilizadas como parámetros y valores de retorno en los métodos sean Serializable y que los objetos que a su vez contengan también sean Serializable
3. En tu applicationContext defines el bean que provee el servicio, llamémosle ahorita "servicio"
4. Creas un RmiServiceExporter de Spring:

<bean class="org.springframework.remoting.rmi.RmiServiceExporter">
  <property name="registryPort" value="1199" /><!-- o el puerto TCP que tu quieras -->
  <property name="servicePort" value="1199"/>
  <property name="serviceName="MiServicio"/>
  <property name="service" ref="servicio" /><!-- aqui le pasas tu bean -->
  <property name="serviceInterface" value="nombre.completo.de.la.Interfaz" />
</bean>

Con eso tienes publicado el servicio cuando levanta tu app. Para conectarte a ella puedes hacerlo a patín, o si el cliente también tiene Spring, define un bean así:

<bean id="miCliente" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
  <property name="serviceUrl" value="rmi://ip_servidor:1199/MiServicio" />
  <property name="serviceInterface" value="nombre.completo.de.la.Interfaz" />
</bean>

Ese bean lo inyectas a los componentes que necesiten invocar el servicio y listo.

PERO... en tu bean "servicio" debes considerar que los métodos que estás publicando pueden ser invocados de manera simultánea por varios clientes. Eso aplica igual si haces un web service con XML sobre HTTP o si usas Thrift o Protobuf o RMI. La diferencia entre todos ellos es el transporte. No hay un contenedor ni biblioteca que mágicamente haga que tu componente funcione bien en ambientes concurrentes si tu código no está listo para eso.

Imagen de ezamudio

concurrencia

Y si piensas "ah pues es muy difícil esto, mejor me hago puros clientes Swing o JavaFX y que se conecten directo a la base de datos", pues de todas maneras no te escapas, tienes que manejar la concurrencia en la base de datos porque tienes que considerar que habrá dos o más usuarios corriendo su app y que van a tratar de editar el mismo registro de la misma tabla, o van a ejecutar un proceso que va a afectar los mismos datos, de modo que tienes que manejar transaccionalidad, dirty reads, optimistic o pessimistic locking, etc.

Imagen de ezamudio

Griffon

Si quieren hacer apps en Swing, les recomiendo seriamente mejor usar Griffon. Es como Grails para escritorio. Les dejo un screencast donde pueden ver algo de la arquitectura y características principales, seguidas de una demo, para que vean cómo se programa en Griffon.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">