1. persistence.xml 2. Member.java package hellojpa ; import javax.persistence.* ; @Entity // JPA 의 관리 대상이 된다 . public class Member { @Id @GeneratedValue @Column (name = "MEMBER_ID" ) private Long id ; @Column (name = "USERNAME" ) private String username ; // // @Column(name = "TEAM_ID") // private Long teamId; @ManyToOne @JoinColumn (name = "TEAM_ID" ) private Team team ; public Long getId () { return id ; } public void setId (Long id) { this . id = id ; } public String getUsername () { return username ; } public void setUsername (String username) { this . username = username ; } public Team getTeam () { return team ; } public void setTeam (Team team) { this . team = team ; } } 3. Team.java package hellojpa ; import javax.persistence.* ; import java.util.ArrayList ; import java.util.List ; @Entity public class Team { @Id @GeneratedValue @Column (name = "TEAM_ID" ) private Long id ; private String name ; // Team 객체에서 Member 클래스를 참조하기 위해 @OneToMany (mappedBy = "team" ) private List<Member> members = new ArrayList<>() ; public Long getId () { return id ; } public void setId (Long id) { this . id = id ; } public String getName () { return name ; } public void setName (String name) { this . name = name ; } public List<Member> getMembers () { return members ; } public void setMembers (List<Member> members) { this . members = members ; } } 4. JpaMain.java package hellojpa ; import javax.persistence.EntityManager ; import javax.persistence.EntityManagerFactory ; import javax.persistence.EntityTransaction ; import javax.persistence.Persistence ; import java.util.List ; public class JpaMain { public static void main (String[] args) { // 엔티티 매니저 팩토리는 하나만 생성해서 애플리케이션 전체에서 공유 EntityManagerFactory emf = Persistence. createEntityManagerFactory ( "hello" ) ; // DB 커넥션을 얻는 일관적인 행위를 할때마다 EntityManager 를 만들어줘야한다 . // 엔티티 매니저는 쓰레드간에 공유 X ( 사용하고 버려야 한다 ) EntityManager em = emf.createEntityManager() ; // // JPA 의 모든 데이터 변경은 트랜잭션 안에서 실행 . EntityTransaction tx = em.getTransaction() ; tx.begin() ; // 트랜젝션 시작 try { // 저장 Team team = new Team() ; team.setName( "TeamAA" ) ; em.persist(team) ; Member member = new Member() ; member.setUsername( "member22" ) ; member.setTeam(team) ; em.persist(member) ; em.flush() ; em.close() ; Member findMember = em.find(Member. class, member.getId()) ; List<Member> members = findMember.getTeam().getMembers() ; for (Member m : members) { System. out .println( "kkk = " + m.getUsername()) ; } tx.commit() ; } catch (Exception ex) { tx.rollback() ; } finally { em.close() ; } emf.close() ; // 웹 애플리케이션에서 WAS 가 종료될 때 emf 종료 => release //code em.close() ; emf.close() ; } } 문제 1. 콘솔창에 kkk = 결과값이 나오지 않습니다. 문제 2. H2 DB에 저장되지 않습니다. em.flush(); em.clear(); 를 지우고 했을 때는 저장이 되지만 마찬가지로 결과값은 나오지 않았습니다. em.flush(); em.clear();를 붙이니 결과값도, DB에 저장도 되지 않았습니다. 원인 파악 부탁드립니다 ㅠㅠ 디버깅 해보았는데도 잘 모르겠어요 ㅠㅠ
안녕하세요 영한님! 다름이아니라 제가 이해한 내용이 맞나 궁금해서 질문드립니다. 시퀀스 전략 중 allocationSize에서 이 값이 50이면 시퀀스를 한 번에 50씩 증가하고 그만큼 메모리에 1~50까지 식별자를 할당하는데 50까지 차면(51일 때) 시퀀스 값을 한 번 더 50 증가시켜 100까지 할당하는 방식이라고 하셨습니다. 처음에 조금 헷갈리거나 이해가 안갔던 부분은 시퀀스 값이 1이면 애플리케이션에서 1~50까지 사용하고 시퀀스 값이 2이면 애플리케이션에서 51~100까지 기본 키를 사용하는 건데, 제가 이를 이해한 것은 네트워크시간에 배우는 TCP의 슬라이딩 윈도우 개념과 비슷하지 않나 해서 이와 유사한 아이디어라고 이해하였는데 이렇게 생각해도 되나요??ㅎㅎ; 시퀀스 값 1마다 기본키 50으로 묶이는건 세그먼트와 바이트번호 관계처럼 묶이는(?) 개념이라 생각이 듭니다. 감사합니다 // 슬라이딩 윈도우
atomic연산에 한해, 모든 쓰레드가 동일 객체에 대해서 동일한 수정 순서를 관찰하는 말이.. 0,2,3,39,9,10,7 순서로 다중쓰레드를 이용해서 바뀔 A데이터가 있을때 마지막 A데이터를 이용했을때가 2인상황에서 몇프레임지난후 현재상황에서 A데이터를 변경해준 쓰레드들중 마지막에 9라는 값을 넣어줬주고 A데이터의 값을확인하면 무조건 9라는 값이 나오는것이 아닌 2이후 3,39,9중 하나가 나올수있다는 건가요?
제목과 같습니다. mutex 라이브러리를 이용한 강의 내용의 mutex m은 기본적으로 busy waiting이라고 말할 수 있나요? 뒷 강의 내용에서 나오는 mutex 변수를 Spinlock 구조로 되어있다고 이해해도 문제가 없는걸까요? (강의내용 11분 50초경) 이번 강의에서 t1과 t2가 Push를 하게 될때, 만약 t1이 lock을 붙잡고 있으면, t2는 Context Switching 이라거나 Event 방식으로 기다리지 않고 Busy waiting 하는것인지 궁금해서 문의 남깁니다. 제가 구글링을 통해 찾아본 해외 자료 느낌에서는 윈도우 환경과 VS에서 코딩하는 경우 Busy waiting을 하지 않는것처럼 나오는데, 만약 그렇다면 이것이 뒷 강의에서 설명하는 Lock 구현 방식중 2번의 Context Switching인건지 3번의 Event 방식인지도 궁금합니다.
안녕하세요. 제가 람다랑 optional, 컬렉션 그런부분을 아직 잘몰라서 자바 공부가 더 필요한데요. 이 부분 듣다가 궁금증이 있어서 질문 남기게 됐습니다. - 중점적인 내용은 `findName 메소드를 findById메소드 처럼 구현하면 안되냐`입니다. -> 다른 질문글을 통해 id는 유일한 기본키로 사용되서 중복이 없고, 이름은 중복이 있을 수 있다고 하셨습니다. 제가 코드는 정확히 모르겠지만 영한님의 강의를 들어보며 추측해보면 -> store - 객체 -> , values() - 값들중 -> . stream() - 모두 돌리는데 -> .filter() - 가로안에 있는 조건에 해당하는 값이 걸리면 -> .findAny() -리턴해라 이런 의미의 식 같습니다. 또 filter 안에 있는 람다표현식?은 member를 받아서 받은 멤버 객체의 name이 findByName 메소드 호출시 매개변수로 받은 name과 같은지를 체크한 것 같구요. 여기서 궁금한점이 store의 member를 하나씩 쭉 돌리는데 우리가 매개변수로 넘겨준 name과 같은 member를 모두 optional에 담아서 반환하는건가요? 즉, findById는 중복 없이 Optional에 하나의 Member 객체만 담아서 반환되어 코드를 저렇게 짠 것이고 findByName은 중복이 있을 수 있어, 매개변수로 받은 name과 같은 모든 member 객체를 optional에 담아 반환해주는 코드인건가요?
예제에서는 DB 리소스 설정 이후에도 루트접근이 가능해 보이는데, 저의경우는 접근이 불가능합니다 아래 이미지는 서버 기동 직후, 브라우저를 통해 루트 접근시 차단이 되는 부분에 BreakPoint 를 잡아 캡쳐했습니다. 익명 사용자의 경우에 허용되어야 할 `/` 웹 루트 경로가 Denied 되는 것은 어느 부분이 문제일까요.. DB 연동은 잘 처리가 되었으나 이부분에서 막힙니다. 특별히 설정을 바꾼것이 없는데 DB 연동 처리 이후, 계속 여기서 부터 막힙니다. 어느 부분부터 살펴봐야 해결이 될까요..? 혹시 정상인가요? ( 지난 강의 돌려보다가 문뜩 생각이 듭니다) 혹제 제가 놓친부분에 대해 조언을 구합니다. 읽어주셔서 감사드립니다.
wsasend가 멀티쓰레드환경을 보장하지 않아 lock을 걸어준다고 하셨는데 어떤부분을 보장하지 않는 건가요? 버퍼문제라면 혹시 이번 수업의 코드는 임시로 event마다 독립적인 버퍼를 가지게 했으니 lock을 안걸어주어도 되나요? wsarecv 는 멀티쓰레드환경에서 문제가 발생하지 않나요?
안녕하세요 ㅎㅎ 웹 서버의 경우 포트가 http는 80 https 는 443이라고 하셨는데 , 우리가 유튜브로 음악을 듣는 동시에 네이버로 검색을 한다면 둘다 웹 서버를 이용하는 것이고 창이 2개 띄어져 있을텐데 둘다 80 또는 443으로 접속하는 건가요?(중복으로) 아니면 중복 포트는 불가능하니 다른 포트로 접속을 하게 되는건가요? 예를들어 하나는 80 하나는 xx
패킷이 크면 전송할 때 조각내서 보낸다고 이해했습니다. 또한, tcp 에 조각낸 패킷의 순서정보 또한 같이 보내는 걸루요 서버 입장에서 받은 패킷과 tcp 순서 정보를 맞춰서, 순서가 잘못됬다고 패킷을 보낸 클라이언트한테 다시 요청하는 부분의 필요성이 이해가 가지 않습니다. 서버가 조각난 패킷의 순서가 잘못됬다는 걸 인지 했다면, 클라이언트 - 서버간 수많은 노드를 거쳐서 다시 보내는 것보다, 서버 내에서 순서정보를 가지고 패킷을 다시 맞추는게 더 좋은게 아닌 건가요..? 패킷이 크면 클수록 저런 왕복을 여러번 해야할 것 같아서요. http 를 공부하는게 처음이라 잘못된 질문일 수 있습니다.
목록페이지를 그냥 들어가면 # 이름 이렇게 잘 뜹니다. 하지만 회원등록을 하고 난 후 회원목록에 들어가면 Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.thymeleaf.exceptions.TemplateProcessingException: Could not parse as expression: "${member.id" (template: "members/memberList" - line 19, col 15)] with root cau member.id 를 찾을수없다고 나옵니다 ㅠㅠ
안녕하세요. 방학기간을 통해 스프링에 대해 공부하고 있는 대학생입니다. 다름이 아니라 스프링 핵심원리 강의에서 역할과 구현을 분리하라고 배웠습니다. 그래서 만약 '회원 저장소'를 만든다고 하면 pubic interface MemberRepository{ void save(Member member); Member findById(Long memberId); } 을 만들고 필요한 구현체를 따로 만들었습니다. 메모리를 이용한다면 public class MemoryMemberRepository implements MemberRepository { private static Map<Long, Member> store = new HashMap<>(); @Override public void save(Member member) { store.put(member.getId(), member); } @Override public Member findById(Long memberId) { return store.get(memberId); } } 이런 식으로 만들고, 만약 JPA를 이용한다면 public class MemberJpaRepository implements MemberRepository { @PersistenceContext private EntityManager em; public void save(Member member) { em.persist(member); } public Member findById(Long id) { Member member = em.find(Member.class, id); return member; } } 이런 식으로 만들어서 사용했습니다. 여기서 스프링데이터JPA를 사용하기 위해선 인터페이스에 JpaRepository를 상속받아야하는데 그러면 기존에 있던 MemberRepository에 상속받아서 사용하면 되나요? 그런데 MemberRepository에서 JpaRepository를 상속받게 되면 기존에 MemberRepository 구현체들이 JpaRepository까지 모두 구현해야하는 문제가 있고, MemberReposity에서 사용하는 메소드 이름과 JpaRepository에서 사용하는 메소드 이름이 같으면 MemberRepository를 주입받아 사용하는 다른 클래스에도 문제가 발생했습니다. 이래저래 글이 길었지만 그래서 어떻게 스프링데이터 JPA를 사용하면서 역할과 구현을 구분할 수 있을까요?
조인/ 단일테이블 / 구현클래스마다 테이블 이 세가지 전략에 대한 소스코드를 교재에서 확인할 수 있는데요 세 전략 모두 Item 클래스를 추상클래스로 선언했음에도 아래와 같은 차이를 보입니다. '조인' / '단일테이블' 의 경우에는 ITEM 테이블이 생성된 반면,[그림7.3, 그림7.4] '구현클래스마다 테이블'에서는 ITEM 테이블이 생성되지 않는 것으로 이해되고 있습니다.[그림 7.5] 왜 이런 차이를 발생시키는 것인지 궁금합니다. 별개로, 강의에서는 '조인'/'단일테이블' 설명하실 때 Item클래스를 추상클래스로 선언하지 않으셔서 이 부분도 혼동을 주고있습니다.
주문취소쪽 테스트하다가 궁금한점 있어 질문드립니다. 취소할 주문ID를 조회하고 Order order = orderRepository.findOne(orderId); order.cancel(); 로 주문취소하기 전에 orderItems에 값이 넣어져 있는지 모르겠습니다. Order와 OrderItem은 @OneToMany로 기본이 LAZY 로딩이라 orderItems을 직접 호출하기 전까지는 데이터를 조회하지 않는거로 알고 있는데 어떻게 orderItems에 값이 채워져서 취소가 되는지요?... for (OrderItem orderItem : orderItems ) { orderItem.cancel() ; } 저 for문 시점에 데이터를 조회하면 이해하겠는데 디버깅해보면 order를 조회할때 이미 값이 다 채워져 있습니다...
강의에서 영한님께서는 커맨드와 쿼리를 구분하는 것을 선호하신다고 하셨습니다. 그래서 알아보니 이런걸 CQRS라고 하던데 회원 정보를 update시 update command 메소드 실행 후 보통같으면 update메소드 자체의 반환값으로 member객체나 member id를 받는데, 이것을 명령과 질의를 구분해 memberService.update() 후 memberService.findOne을 실행하면 결과적으로 쿼리문을 한번 더 실행을 하게 되잖아요? update 메소드 내에서도 findOne이라는 메소드를 호출하니깐요. 이렇게 명령과 질의를 분리하였지만 그 대가로 쿼리문을 한번 더 호출하게 된 셈인데 쿼리문을 한번 더 호출해서 명령과 질의를 구분하는 것이 많이 효율적인 패턴인가요?
