Duda JAVA - API REST + springboot

#2 Ya, ya, si el problema es que no he hecho nunca nada relacionado con almacenar datos en memoria. Entonces no sé ni cómo hacerlo, ni cómo buscar documetnación para hacerlo.

Yo lo único que he hecho ha sido persistir datos en base de datos y recuperarlos de ahí, nunca he trabajado con memoria.

Tienes algun link con documentación de como se podría hacer?

#4 Si, creo que va más enfocado a lo que dices, en la explicación que me han dado sobre cómo hacer esa parte he apuntado esto:

• Usar Collections
• Hacerse un productcollectionrepository
• implementacion de esa interfaz - que tenga un map (id,producto) y dentro se implementan los métodos
• Streams filtrado

Pero aún con esto sigo un poco perdido xD

De hecho, os copio literal el texto:

PRODUCT SERVICE
We need to create a simple WEB service exposing an CRUD rest api to manage products.
Additionally the api will allow searching by product attributes.
Product attributes

• ID
• Name
• Description

Notes:

• Creating operation should have two entry points, sync(rest api) and async(event listener, it
  can be just a regular method for the sake of simplicity).
• Products should be kept in memory in the java collection you think best fit.[/i]

edit: #6 podría ser lo que dices algo así?: https://github.com/flojdek/spring-boot-java-lru-cache-rest

Vas muy perdido, postea todas tus dudas / respuestas que dirías al entrevistador y te ayudamos xd

#19 Era el primer ejemplo, coño XDD Luego ya usaba H2 y después Mongo.

Edit: este era el ejemplo.

public abstract class AbstractMapService<T, ID> {

protected Map<ID, T> map = new HashMap<>();

Set<T> findAll(){ return new HashSet<>(map.values());}

T findById(ID id){ return map.get(id); }

T save(ID id, T object){
    map.put(id, object);
    return object;
}

void deleteById(ID id){ map.remove(id); }

void delete(T object){ map.entrySet().removeIf(entry -> entry.getValue().equals(object)); }
}

#23 con un hashmap normal no bloquea nada. El principal problema es cuando añades/eliminas elementos del hashmap y tiene que hacer un rehash.

Las lecturas son lockfree en ambos, las escrituras están sincronizadas en el concurrent.

Pero vamos aún así. Si haces cosas como

val ent = repo.findById(1)
...
ent.updateStock(X)
repo.save(ent)

Con peticiones concurrentes pues va a estar mal también. La forma de arreglarlo sin los distintos tipos de transacciones ni select for share/update es con versionado (vamos un optimistic locking) o hacer en algo parecido a actores de tal forma que todas los updates de un producto con id X fueran al mismo actor (que se escapa por mucho de lo que te piden) o con disruptor filtrando eventos. Sin contar con los syncronized/locks de toda la vida vamos.

#27 Es como escribir Chuacheneguer, nadie atina nunca, jamás

#28 Prácticamente siempre que trabajes con colecciones vas a tener que sobreescribir equals y hashcode; en mi opinión es una práctica que debería seguirse siempre, aunque no sea necesaria. No hacerlo puede tener efectos la mar de divertidos, sobre todo cuando trabajas con colecciones que aseguran la unicidad de sus componentes, como Set.