tipos - ¿Debo preocuparme por los problemas de concurrencia en mi código Flex/AIR?

transacciones base de datos pdf (3)

Después de enterrarme en Flex y Actionscript durante varios meses, volví a .NET; y estoy un poco reprimido por todos los modos de los que tengo que elegir, o alternativamente, debo elegir y orquestar.

Por el contrario, Flex / AIR tiene prácticamente un conjunto simple pero completo de llamadas SDK para la manipulación de datos y archivos, cada uno con variantes síncronas y asíncronas. Es mucho más fácil de entender y usar de manera consistente.

Roger tiene razón desde mi experiencia. Flex / AS # simplemente funciona. .NET, cada vez menos (de sobrecarga de opción, en mi humilde opinión). Una consecuencia es que .NET se adapta mejor a los escenarios de borde; pero si Flex / AS3 puede manejar sus requisitos, probablemente lo haga fácilmente. Piensa en la Regla 80/20 (o probablemente sea mejor).

Creo que su pregunta ha sido abordada por Roger, pero permítanme decirlo de la manera en que creo que lo escuché.

Su método es de subproceso único (junto con otra actividad de IU) en un subproceso de interfaz de usuario común. Pero los recursos (archivos, puertos dbms, etc.) suelen pasar por una secuencia simple que normalmente se configura de esta manera:

Crear una instancia de un objeto de la clase de recurso deseado,
Registre un controlador de eventos para el evento de retorno en el objeto (digamos "fileonOpen"),
Llame al método de ejecución asincrónico para el objeto (digamos "file.open").
El ciclo de eventos UI continúa,
El recurso finalmente completa su ejecución del método y desencadena el controlador de eventos que registró, que ahora se ejecuta en el hilo de UI. Tal vez la respuesta a su pregunta es que al controlador de eventos se le da un argumento que es el objeto al que pertenece, por lo que puede eliminarlo de su colección. Es de suponer que su objeto se identificará lo suficiente como para evitar confusiones al tratar con la colección a la que pertenece. Si se trata de una fila de resultados de la base de datos, supuestamente conocerá su propio valor PK. Los objetos de archivo tienen propiedades como nativePath, isDirectory, parent (otro objeto File), etc.

Tengo una situación en la que estoy comenzando una serie de objetos que, cuando están listos para manejar algunos datos de entrada, llaman a un controlador.

Ese controlador obtiene un conjunto de datos de un ArrayCollection de solicitudes pendientes, lo asigna al objeto y elimina el conjunto de datos de ArrayCollection.

(No puedo extraer desde ArrayCollection porque necesito buscar a través de él para encontrar un conjunto de datos apropiado, no siempre es el que está en la parte superior).

¿Es posible que dos objetos puedan llamar a mi controlador de tal manera que (1) al primero se le asigne un conjunto de datos, (2) al segundo se le asigne el mismo conjunto de datos antes de que la instancia del manejador que lo atendió lo haya eliminado y supongo (3) la segunda instancia de los errores del controlador al intentar eliminar el conjunto de datos de ArrayCollection.

No estoy lo suficientemente familiarizado con el tiempo de ejecución de Flash Player para saber si este escenario de falla es posible, o si debería tomarme más tiempo para poner algún tipo de bloqueo en su lugar para evitarlo.

Editar: Las respuestas hasta el momento dan buenas críticas para Flex, pero no estoy seguro de que respondan la pregunta. Para ser claro, no estoy tratando de decidir si usar Flex o no.

Si tengo un método que:

Obtiene un fragmento de datos de algún lugar de ArrayCollection
Algo con esos datos
Elimina esa información de ArrayCollection

¿Es posible que otra invocación de ese mismo método pueda hacer # 1 después de que la primera invocación haga # 1 pero antes que # 3?

le dorfier, dijo que Flex / AS "simplemente funciona". ¿Puede aclarar que "simplemente funcionará" en este caso?

No es necesario realizar el bloqueo, pero es posible que desee realizar un seguimiento del orden de las modificaciones en su estado. Las diferentes llamadas asincrónicas que están en juego podrían devolver y modificar el estado de su modelo en un orden que es diferente de cuando se emitieron las llamadas asincrónicas.

Las aplicaciones Flex y AIR tienen un único modelo de programación con rosca. Sin embargo, su arquitectura se basa en E / S asíncronas para las interacciones con el nivel de servidor.

Ahora, en una aplicación Java Swing o .NET Winforms, se pueden realizar interacciones de E / S en un hilo de fondo y reunir argumentos / resultados desde y hacia el hilo principal de la GUI. (Esas bibliotecas de UI gráficas no permiten que otros subprocesos cambien el estado de los objetos / widgets del juego de herramientas gráficas, y por lo tanto, las interacciones de datos se deben calcular a partir de otros subprocesos de procesamiento en segundo plano).

Por el contrario, la biblioteca de clases de E / S de Flex y AIR está escrita donde estas clases implementan operaciones de E / S de forma asíncrona. Por ejemplo, para hacer un HTTP GET, se puede invocar el método HttpSerivce send (), que no es una llamada de bloqueo. En su lugar, se puede suministrar un cierre de ActionScript3 para manejar el resultado siempre que la llamada se complete y se devuelva.

Mientras tanto, la aplicación Flex / AIR puede permitir que la GUI continúe siendo completamente interactiva para el usuario. Incluso puede mostrar un indicador de progreso y / o un botón Cancelar.

Entonces, aunque el modelo GUI de un solo subproceso Flex / AIR es más simple y fácil de programar que las aplicaciones Java Swing o .NET Winform de subprocesos múltiples, es capaz del mismo tipo de comportamiento UI sofisticado que el estilo de los ricos. aplicaciones de cliente.

Una sencilla interfaz gráfica de usuario guiada por eventos, asíncrona (a través de llamadas de servicio y / o mensajería), junto con cierres de ActionScript3 para el procesamiento de resultados o fallas, es la receta secreta de Flex / AIR para dominar el mundo. (Por supuesto que debería mencionar el buen soporte para propiedades, eventos y buena unión declarativa o imperativa como parte de esta estrategia de conquista mundial).

La respuesta a tu pregunta, como la has descrito, es no. Si bien conocer el registro de eventos, el envío de eventos, las prioridades, la asincronía, etc., es todo valioso, el hecho es que está haciendo el trabajo de modificar ArrayCollection dentro del alcance de una sola función en el hilo principal, que será seguido por la segunda invocación de esa función, también en el hilo principal, para que no tenga nada de qué preocuparse en términos de concurrencia: si bien es cierto que es posible que no sepa qué objeto llega primero (por muchas razones), puede ser seguro que el segundo obtendrá el producto del trabajo realizado por el primero.

Entonces no, estás listo para ir. Rock en!