Quel est le problème principal de cette implémentation du type composite dans la base de données? TIMESTAMP sans fuseau horaire Erreur de syntaxe! NULL dans le code Absence de CTE, lisibilité Problèmes de portabilité dus à SERIAL «TICKET_TYPE» n'a pas été déclaré dans la base de données Ce n'est pas la dernière valeur au niveau de INTEGER
Pourquoi avons-nous besoin des starters Spring Boot alors que nous pouvons tout faire avec Spring?
Que perdrais et que gagneriez-vous avec le polling explicite au lieu de @KafkaListener?
Quelles technologies préfères-tu ?
Le consommateur DLT était-il dans le même service que le principal ? Pourquoi l'écouter à nouveau et le journaliser ?
S'il y a plusieurs offres de différentes entreprises, selon quels critères feras-tu ton choix ? Nomme trois.
Choisissez la réponse la plus appropriée - Le coordinateur dit qu'il ne supporte pas l'asynchronie - Il manque un mécanisme de cohérence des transactions entre le Service B et le Service A - Il manque un chiffrement dans les connexions REST - Il n'y a pas de gestion des erreurs dans les enregistrements de service
Que faites-vous avec les sujets DLT ?
Quel est le problème principal de cette implémentation? - Le port '83' peut déjà être occupé sur l'hôte - Organisation inefficace de l'apparence - Surcharge du port en raison de l'ordre incorrect de la commande - La configuration utilise une version confidentielle - Chemin incorrect dans la dernière compilation version : '3.8' services: art-marketplace: build: context : ./art-market ports: - "83:83" networks: - art-network réseaux: art-network: driver : overlay
Quelle est la principale cause du comportement incorrect du code? L'invariance des objets est violée L'état d'interruption n'est pas géré La performance se dégrade en raison du verrouillage Le conflit d'objets de verrouillage conduit à une situation de blocage Surcharge de synchronisation des ressources États d'objets non initialisésimport java.util.concurrent.*; class Competition { private final Object lock = new Object(); public void syncMethodA(Competition competitor) { synchronized (lock) { try { Thread.sleep(100); } catch (InterruptedException e) {} competitor.syncMethodB(this); } } public void syncMethodB(Competition competitor) { synchronized (lock) { try { Thread.sleep(100); } catch (InterruptedException e) {} competitor.syncMethodA(this); } } } public class FitnessApp { public static void main(String[] args) { Competition comp1 = new Competition(); Competition comp2 = new Competition(); Thread t1 = new Thread(() -> comp1.syncMethodA(comp2)); Thread t2 = new Thread(() -> comp2.syncMethodB(comp1)); t1.start(); t2.start(); } }
Quel est le problème principal de cette implémentation? - Les tableaux non optimisés montrent la taille de l'image - La coupe de l'image Docker dans RUN peut poser problème - Plusieurs CMD, seul le dernier est effectif - L'opération de suppression ne prend pas en compte le filtrage par l'image "visible"
Parle-moi de toi, pourquoi cherches-tu maintenant, qu'est-ce que tu cherches?
Avez-vous une expérience avec des domaines fintech — paiements, finances, facturation, intégration?
Mise en œuvre incorrecte de la logique de gestion des erreurs avec onErrorResume Aucune différenciation dans la gestion des erreurs dans handleEnrollmentError Absence d'injection en fonction du contrôleur La méthode handleEnrollmentError n'utilise pas de paramètres CourseController n'est pas enregistré depuis dix ans
Quels sont les niveaux d'isolation des transactions en SQL et lequel est défini par défaut dans PostgreSQL?
Quel est le problème principal de cette implémentation - Définition incorrecte des statuts HTTP avec des types d'exceptions - Mauvaise configuration de l'injection de dépendances - Les écouteurs asynchrones ne sont pas engagés - Gestion des exceptions non standard dans le gestionnaire - Configuration incorrecte des beans - @Autowired n'est pas utilisé pour le développement de la dépendance
Quel est le problème principal de la structure de solution choisie? - Rigidité dans le type, faible flexibilité - Violation du polymorphisme lors du traitement des éléments - Pas de méthode de fabrique pour WardrobeItem - Pas de pattern Adaptateur pour les nouveaux optimiseurs - Opérations coûteuses dans l'optimisation
Que retourne le producteur s'il envoie un ID qui a déjà été envoyé il y a quelque temps (période d'idempotence de 6 heures) ?
Le WardrobeManager doit utiliser @Autowired Il manque une classe pour gérer les binaires Gestion des transactions manquante ItemRepository n'est pas annoté avec @Repository Utilisation du constructeur au lieu du conteneur Spring pour créer le composant Le constructeur de WardrobeController n'utilise pas @Autowired
Que faire avec le contexte MDC dans Kafka?
