Transactional failure recovery for a distributed key-value store

With the advent of cloud computing, many applications have embraced the ensuing paradigm shift towards modern distributed key-value data stores, like HBase, in order to benefit from the elastic scalability on offer. However, many applications still hesitate to make the leap from the traditional relational database model simply because they cannot compromise on the standard transactional guarantees of atomicity, isolation, and durability. To get the best of both worlds, one option is to integrate an independent transaction management component with a distributed key-value store. In this paper, we discuss the implications of this approach for durability. In particular, if the transaction manager provides durability (e.g., through logging), then we can relax durability constraints in the key-value store. However, if a component fails (e.g., a client or a key-value server), then we need a coordinated recovery procedure to ensure that commits are persisted correctly. In our research, we integrate an independent transaction manager with HBase. Our main contribution is a failure recovery middleware for the integrated system, which tracks the progress of each commit as it is flushed down by the client and persisted within HBase, so that we can recover reliably from failures. During recovery, commits that were interrupted by the failure are replayed from the transaction management log. Importantly, the recovery process does not interrupt transaction processing on the available servers. Using a benchmark, we evaluate the impact of component failure, and subsequent recovery, on application performance.

Mapping energy efficiency barriers

In the E2KW Conference we present the research we are following in collaboration with ANESE (Asociación de Empresas de Servicios Energéticos) to check the interaction among barriers that previous studies have identified. We focus our research question in the information problems that include a number of specific problems such as lack of information, asymmetric information and the well-documented principle-agent problem. Asymmetric information problems occur when one party involved in a transaction has more information that the other, which may lead to suboptimal energy decisions. The fact that energy efficiency cannot be observed (ie. it is ?invisible?) further intensifies this asymmetric information barrier.

Analysis of alternative tendering mechanisms for transportation Public-Private Partnerships

This paper describes a theoretical model based primarily on transaction costs, for comparing the various tendering mechanisms used for transportation Public-Private Partnership (PPP) projects. In particular, the model contrasts negotiated procedures with the open procedure, as defined by the current European Union legislation on public tendering. The model includes both ex ante transaction costs (borne during the tendering stage) and ex post transaction costs (such as enforcement costs, re-negotiation costs, and costs arising from litigation between partners), explaining the trade-off between them. Generally speaking, it is assumed that the open procedure implies lower transaction costs ex ante, while the negotiated procedure reduces the probability of the appearance of new contingencies not foreseen in the contract, hence diminishing the expected value of transaction costs ex post. Therefore, the balance between ex ante and ex post transaction costs is the main criterion for deciding whether the open or negotiated procedure would be optimal. Notwithstanding, empirical evidence currently exists only on ex ante transaction costs in transportation infrastructure projects. This evidence has shown a relevant difference between the two procedures as far as ex ante costs are concerned, favouring the open procedure. The model developed in this paper also demonstrates that a larger degree of complexity in a contract does not unequivocally favour the use of a negotiated procedure. Only in those cases dealing with very innovative projects, where important dimensions of the quality of the asset or service are not verifiable, may we observe an advantage in favour of the negotiated procedure. The bottom line is that we find it difficult to justify the employment of negotiated procedures in most transportation PPP contracts, especially in the field of roads. Nevertheless, the field remains open for future empirical work and research on the levels of transaction costs borne ex post in PPP contracts, as well as on the probabilities of such costs appearing under any of the procurement procedures.

Simulación de seguimiento de blancos en sistemas radar. Parte 2

El proyecto consiste en el diseño y estudio de un software cuyas prestaciones estén orientadas a gestionar una simulación de un sistema de radar. El prototipo de este entorno de simulación se ha realizado en el lenguaje Matlab debido a que inicialmente se considera el más adecuado para el tratamiento de las señales que los sistemas de radar manejan para realizar sus cálculos. Se ha escogido como modelo el software desarrollado por la compañía SAP para gestionar los E.R.P.s de grandes empresas. El motivo es que es un software cuyo diseño y funcionalidad es especialmente adecuado para la gestión ordenada de una cantidad grande de datos diversos de forma integrada. Diseñar e implementar el propio entorno es una tarea de enorme complejidad y que requerirá el esfuerzo de una cantidad importante de personas; por lo que este proyecto se ha limitado, a un prototipo básico con una serie de características mínimas; así como a indicar y dejar preparado el camino por el que deberán transcurrir las futuras agregaciones de funcionalidad o mejoras. Funcionalmente, esto es, independientemente de la implementación específica con la que se construya el entorno de simulación, se ha considerado dividir las características y prestaciones ofrecidas por el sistema en bloques. Estos bloques agruparán los componentes relacionados con un aspecto específico de la simulación, por ejemplo, el bloque 1, es el asignado a todo lo relacionado con el blanco a detectar. El usuario del entorno de simulación interactuará con el sistema ejecutando lo que se llaman transacciones, que son agrupaciones lógicas de datos a introducir/consultar en el sistema relacionados y que se pueden ejecutar de forma independiente. Un ejemplo de transacción es la que permite mantener una trayectoria de un blanco junto con sus parámetros, pero también puede ser una transacción la aplicación que permite por ejemplo, gestionar los usuarios con acceso al entorno. Es decir, las transacciones son el componente mínimo a partir del cual el usuario puede interactuar con el sistema. La interfaz gráfica que se le ofrecerá al usuario, está basada en modos, que se pueden considerar “ventanas” independientes entre sí dentro de las cuáles el usuario ejecuta sus transacciones. El usuario podrá trabajar con cuantos modos en paralelo desee y cambiar según desee entre ellos. La programación del software se ha realizado utilizando la metodología de orientación a objetos y se ha intentado maximizar la reutilización del código así como la configurabilidad de su funcionalidad. Una característica importante que se ha incorporado para garantizar la integridad de los datos es un diccionario sintáctico. Para permitir la persistencia de los datos entre sesiones del usuario se ha implementado una base de datos virtual (que se prevé se reemplace por una real), que permite manejar, tablas, campos clave, etc. con el fin de guardar todos los datos del entorno, tanto los de configuración que solo serían responsabilidad de los administradores/desarrolladores como los datos maestros y transaccionales que serían gestionados por los usuarios finales del entorno de simulación. ABSTRACT. This end-of-degree project comprises the design, study and implementation of a software based application able to simulate the various aspects and performance of a radar system. A blueprint for this application has been constructed upon the Matlab programming language. This is due to the fact that initially it was thought to be the one most suitable to the complex signals radar systems usually process; but it has proven to be less than adequate for all the other core processes the simulation environment must provide users with. The software’s design has been based on another existing software which is the one developed by the SAP company for managing enterprises, a software categorized (and considered the paradigm of) as E.R.P. software (E.R.P. stands for Enterprise Resource Planning). This software has been selected as a model because is very well suited (its basic features) for working in an orderly fashion with a pretty good quantity of data of very diverse characteristics, and for doing it in a way which protects the integrity of the data. To design and construct the simulation environment with all its potential features is a pretty hard task and requires a great amount of effort and work to be dedicated to its accomplishment. Due to this, the scope of this end-of-degree project has been focused to design and construct a very basic prototype with minimal features, but which way future developments and upgrades to the systems features should go has also been pointed. In a purely functional approach, i.e. disregarding completely the specific implementation which accomplishes the simulation features, the different parts or aspects of the simulation system have been divided and classified into blocks. The blocks will gather together and comprise the various components related with a specific aspect of the simulation landscape, for example, block number one will be the one dealing with all the features related to the radars system target. The user interaction with the system will be based on the execution of so called transactions, which essentially consist on bunches of information which logically belong together and can thus be managed together. A good example, could be a transaction which permits to maintain a series of specifications for target’s paths; but it could also be something completely unrelated with the radar system itself as for example, the management of the users who can access the system. Transactions will be thus the minimum unit of interaction of users with the system. The graphic interface provided to the user will be mode based, which can be considered something akin to a set of independent windows which are able on their own to sustain the execution of an independent transaction. The user ideally should be able to work with as many modes simultaneously as he wants to, switching his focus between them at will. The approach to the software construction has been based on the object based paradigm. An effort has been made to maximize the code’s reutilization and also in maximizing its customizing, i.e., same sets of code able to perform different tasks based on configuration data. An important feature incorporated to the software has been a data dictionary (a syntactic one) which helps guarantee data integrity. Another important feature that allow to maintain data persistency between user sessions, is a virtual relational data base (which should in future times become a real data base) which allows to store data in tables. The data store in this tables comprises both the system’s configuration data (which administrators and developers will maintain) and also master and transactional data whose maintenance will be the end users task.

Emotions in services: complaint in B2C e-commerce

This study proposes a service recovery (SR) model to describe how cumulative satisfaction, loyalty and word-of-mouth are affected by complaints. The model is based on the role of positive and negative emotions in satisfaction with service recovery (SSR) processes. While prior SSR studies usually investigated only negative emotions and satisfaction with a specific transaction, this research considered both positive and negative emotions.