programacion - plugin java chrome

¿Hay una API de Java de seguimiento/cambio de objeto/versiones por ahí?

Question

Sé de al menos dos potenciadores de código de bytes que modifican el "modelo de objeto" en el tiempo de ejecución para permitir que la transacción se realice de forma transparente. Uno de ellos es parte de Versant VOD, que uso en el trabajo todos los días, y el otro es parte de Terracota. Probablemente hay algunos otros, por ejemplo, en ORM, pero Versant se encarga de eso en mi empresa.

Mi pregunta es, ¿existe una API de código abierto de este tipo que se pueda utilizar por sí misma, independientemente del producto para el que fue diseñada? Se podría decir una API "hackeable". Solo debe rastrear los cambios , no el acceso de lectura, lo que ralentizaría significativamente el código. En otras palabras, no debería requerir el bloqueo explícito de lectura / escritura. Esto requiere acceso a todas las clases que realizan cambios, no solo al modelo de datos, o requiere mantener alguna forma de "versión anterior" en la memoria para hacer una comparación.

El problema que estoy tratando de resolver es que tengo gráficos de objetos "grandes" (32 K a 256 K) que están "serializados" en una base de datos (NoSQL). Son longevos y deben ser re-serializados regularmente para tener un "historial" de los cambios. Pero son bastante caros de serializar, y la mayoría de los cambios son menores.

Podría serializarlos completamente cada vez y ejecutar una diferencia binaria en la secuencia, pero eso suena muy intensivo en la CPU. Una mejor solución sería una API que modifique las operaciones de escritura en el modelo para proteger los cambios, de modo que después de que se almacene la "imagen" inicial, solo sea necesario almacenar el protocolo.

He encontrado algunas preguntas que hablan sobre los Beanutils de Apache Commons para comparar objetos, pero eso no es útil para los cambios en el lugar; Necesitaría hacer un clon completo del modelo entre cada "transacción comercial".

Para reiterar, estoy buscando una API "en memoria", dentro de la misma JVM, que no implique ninguna aplicación de servidor externo. Las API con código nativo están bien si están disponibles en Win, Mac y Linux. La API no tiene que estar actualmente empaquetada de forma independiente; solo tiene que ser posible extraerlo del "proyecto principal" para formar una API independiente (la licencia del proyecto principal debe permitirlo).

Mis gráficos de objetos involucrarán muchos arreglos grandes, y por lo tanto eso necesita ser soportado eficientemente.

Los cambios no se desean solo para la auditoría, sino para que puedan reproducirse o deshacerse. Más precisamente, con el gráfico inicial deserializado y una lista de cambios, debería llegar a un gráfico final idéntico. Además, comenzando con el gráfico final, debería ser posible volver al gráfico inicial aplicando los cambios al revés. Esto utiliza exactamente la misma funcionalidad, pero requiere que el protocolo de cambio mantenga el valor anterior además del nuevo.

La licencia API debe ser compatible con el uso comercial.

[EDITAR] Hasta ahora no obtuve una respuesta útil , y no parece que exista lo que quiero. Eso me deja con una sola opción: hacer que suceda. Publicaré un enlace aquí como respuesta cuando tenga una implementación en funcionamiento, ya que este es el próximo paso en mi proyecto y no puedo seguir adelante sin él.

[EDITAR] Encontré por casualidad esta pregunta un tanto relacionada: ¿Existe una biblioteca de Java que pueda "diferenciar" dos objetos?

Answer 1

Eche un vistazo a la API de repositorio de contenido para Java , que Artifactory utiliza para controlar las dependencias de Maven. El Apache Jackrabbit es la implementación de referencia de este JSR ( JSR-283 versión 2 )

Answer 2

Kryo v1 tenía un serializador que conoce los últimos datos que se serializaron y solo emite un delta. Al leer, conoce los últimos datos recibidos y aplica el delta. El delta se realiza en el nivel de byte. Here está el serializador. La mayor parte del trabajo es hecho por esta clase . Esto podría usarse de varias formas útiles, por ejemplo, redes similares a Quake 3.

Esto se omitió en Kryo v2 porque AFAIK nunca se había puesto en uso. Además, no tenía un extenso conjunto de pruebas. Puede ser portado y puede hacer lo que necesite, o servir como base para lo que necesita.

Arriba también publicado en la lista de correo de serializadores JVM.

Hacerlo en el nivel del objeto sería un poco complicado. Podría escribir algo similar a FieldSerializer que recorre dos gráficos de objetos simultáneamente. Sin embargo, este sería un código independiente, no un serializador Kryo. En cada nivel se podría llamar igual. Escribe un byte para que cuando leas sepas si era igual. Si no es igual, usa Kryo para escribir el objeto. Igual se llamaría muchas veces para el mismo objeto, especialmente para objetos profundamente anidados.

Otra forma de hacerlo es hacer solo lo anterior para los escalares y cadenas, es decir, solo los valores escritos por la clase Output. El problema es caminar dos gráficos de objetos. Para usar Kryo, creo que tendrías que duplicar todos los serializadores para conocer el otro gráfico de objetos.

Posiblemente podría usar Kryo con su propia Salida que recopila valores en una lista en lugar de escribirlos. Use esto para "serializar" su viejo gráfico de objetos. Ahora escriba otra versión de su propia Salida que tome esta lista y úsela para serializar su nuevo gráfico de objetos. Cada vez que se escribe un valor, primero verifíquelo con el siguiente objeto en su lista. Si es igual, escribe un 1. Si no es igual, escribe un 0 y luego el valor.

Esto podría hacerse más eficiente en el uso del espacio utilizando la primera Salida dos veces, una vez en la antigua y una vez en el nuevo gráfico. Ahora tienes dos listas de valores. Utilice estos para escribir una cadena de bits que denota que son iguales. Esto ahorra espacio al escribir un byte completo para cada valor, pero tiene la sobrecarga de una lista adicional. Por último, escribe todos los valores que no sean iguales.

Para terminar esta idea, necesita poder deserializar los datos. Necesitará su propia versión de la clase de entrada que toma una lista de valores del antiguo gráfico de objetos. Su entrada primero lee la cadena de bits (o un byte por valor). Para un valor que era igual, devuelve el valor de la lista en lugar de leer los datos. Si un valor no era igual, llama al súper método para leer de los datos.

No estoy seguro de si esto sería más rápido que hacerlo a nivel de byte. Si tuviera que adivinar, diría que probablemente sería más rápido. El almacenamiento de todos los valores en una lista será un montón de boxeo / unboxing, y este enfoque aún asigna todos los campos, incluso si no han cambiado. Dudo que el rendimiento sea un problema de cualquier manera, así que probablemente solo elija el enfoque más fácil. Es difícil decir cuál es la razón ... resucitar las cosas delta o escribir sus propias clases de Salida / Entrada.

Si tienes ganas de contribuir de nuevo a Kryo, eso sería genial, por supuesto. :)

Answer 3

No sé tal API, pero no puede ser tan complicado:

Una mejor solución sería una API que modifique las operaciones de escritura en el modelo para proteger los cambios, de modo que después de que se almacene la "imagen" inicial, solo sea necesario almacenar el protocolo.

Yo diría que solo necesita 2 componentes: Action y ActionProcessor

Solo necesitas persistir una lista (protocolo) de acciones realizadas.

interface ActionProcessor{
    void perform(Action action);
    void undoToDate(Date date);
} 

iterface Action{
    Date getDate();
    void perform();
    void undo();
}      

Answer 4

Por lo que sé, GemFire ​​es un producto empresarial de piedras preciosas (ahora VmWare) que hace algo similar al OODB de piedras preciosas de piedras preciosas, pero luego para Java. James Foster ha creado una serie de videos sobre cómo funciona Gemstone. Los encontré muy interesantes. Gemstone tiene una versión gratuita para construir pequeños sistemas (Seaside web) con.