Wypowiedzi
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Today Tomorrow Toyota
-
Ja bym zaczął od ustalenia czy tak naprawdę jest to rzeczywisty problem, dotyczący rzeczywistego projektu, czy może jakieś eksperymenty badawcze, żeby sprawdzić jak długo zapytania wykonują się na bazie.
Jeśli eksperymenty to prawdę mówiąc nie znam rozwiązania na przerwanie trwającego zapytania (przynajmniej z poziomu JDBC), ale jeśli faktycznie masz problem w istniejącym systemie ze zbyt długimi zapytaniami, to nie tędy droga. W tym drugim przypadku zacząłbym od indeksowania (tak jak wspomnieli koledzy), a później szedł w stronę cache'owania tych wyników (np. w pamięci za pomocą memcached) albo denormalizacji schematu bazy, jeśli wąskim gardłem są JOINy. Tutaj już dużo zależy od tego na jak daleko idące kompromisy możesz iść w kwestii normalizacji schematu/redundancji danych albo modelu spójności. W rzeczywistych systemach z dużymi obciążeniami rezygnuje się często ze strict consistency na rzecz większej dostępności bazy. De facto, nie można mieć wszystkiego (zgodnie z twierdzeniem CAP). To m.in. jest powód, dla którego ostatnio coraz chętniej spogląda się w stronę rozwiązań zwanych popularnie NoSQL. Oczywiście radzenie sobie z realiami relacyjnych baz danych to temat-rzeka. Chciałem tutaj tylko zasygnalizować pewne możliwości.Michał Kalinowski edytował(a) ten post dnia 25.05.10 o godzinie 14:36
-
-
Ooo. Widzę, że masz tutaj Struts. Myślałem, że piszesz w czystym JSP. Co do kodu, który musisz wpisać to byłoby to m/w coś takiego:
<%
HttpSession session = request.getSession();
String userName = session.getAttribute("userID");
if (userName == null) response.sendRedirect("jakasLokalizacja");
%>
Jest to zdecydowanie nieeleganckie (kod Java w JSP), ale powinno działać. Jak chcesz ładniej to pewnie mieszanka JSTL i EL, czyli coś w stylu: <c:if test="${sessionScope.userId}">...</c:if>. Jak zrobisz jeszcze pod to sprawdzenie dedykowanego taga to już będzie OK :).
-
No to już jest kwestia pewnej architektury i raczej nie ma jednej, dobrej odpowiedzi jak taka implementacja powinna wyglądać. Podział odpowiedzialności byłby natomiast taki, że zarówno uwierzytelnienie (obsługa formularza logowania) jak i aspekt autoryzacji byłyby realizowane zdecydowanie poniżej warstwy prezentacji, tak jak to masz obecnie zrobione. Ew. odsyłam tutaj:
http://en.wikipedia.org/wiki/Multitier_architecture
- 1
- 2
- Następna »
